[sentry-junior]

Companion to getsentry/sentry#129541.

Relay already caps a replay recording at max_replay_uncompressed_size (100 MiB by default) once it is decompressed, but only inside RecordingScrubber. That code runs only for projects that have recording scrubbing turned on and a non-empty PII config. For every other project, only the 10 MiB compressed limit is checked, so a small zlib payload can be stored that inflates to any size every time it is read.

The check now lives in the recording scrubbing step, which runs after filtering and quotas, so each recording is decompressed at most once:

• When recording scrubbing runs, its own decompression enforces the limit. It now reads one byte past the limit and returns ParseRecordingError::TooLarge, instead of truncating and failing on JSON parsing. That maps to TooLarge, which records an ItemTooLarge(ReplayRecording) outcome instead of InvalidReplayRecordingEvent.
• When recording scrubbing does not run, processing Relays call relay_replays::recording::validate_recording. It uses the same header split and decompression helper as the scrubber, but inflates into a sink, so it never buffers the output. Only TooLarge is rejected there. Other malformed recordings, including bodies that are not valid zlib, are left to the consumer as before. Uncompressed JSON bodies are not checked.

TooLarge loses its processing cfg gate because scrubbing can now return it in both configurations.

Refs REPLAY-994

via @DominikB2014.

--

View Session [Sentry]

[linear-code]

REPLAY-994

[DominikB2014]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit db985d1. Configure here.}