[DominikB2014]

Backend only (src/, tests/). Relay companion: getsentry/relay#6587, which applies Relay's uncompressed size limit to every recording, not only scrubbed ones.

Problem

decompress_segment inflated recording segments with an uncapped zlib.decompress before the consumer stored them. Relay bounds the compressed payload at 10 MiB, but only applies its 100 MiB uncompressed bound for orgs that have recording scrubbing enabled with a non-empty PII config. For everyone else nothing checked how large a segment became once inflated, and the consumer stored the client's compressed bytes verbatim.

Change

• decompress_segment now decompresses incrementally via zlib.decompressobj, requesting one byte past the limit so an oversized segment is detected without ever materializing more than one byte over the limit. Segments over the limit raise DropSilently.
• New replay.consumer.max-segment-decompressed-size option, default 100 MiB, FLAG_AUTOMATOR_MODIFIABLE — so the limit can be raised or lowered without a deploy.
• Drops are counted under replays.consumer.recording.oversized_segment and logged with the compressed size and the limit.
• decompress_segment reads the option itself instead of having it passed down through process_message and parse_recording_event.

Behavior for well-formed and already-uncompressed segments is unchanged. zlib.decompressobj returns partial output on a truncated stream where the one-shot zlib.decompress raised, so that case is normalized back to zlib.error to preserve the existing handling.

Rollout note

The default matches the uncompressed bound Relay already applies to scrubbing-enabled orgs, so it should be a no-op for segments produced by SDKs. If it turns out legitimate segments sit closer to the limit than expected, replays.consumer.recording.oversized_segment will show it and the option can be raised immediately. Worth watching that metric before considering this settled.

Refs REPLAY-994

via @DominikB2014.

--

View Junior Session [Sentry]

[linear-code]

REPLAY-994

[DominikB2014]

@cursor review

[cursor]

Stale Bugbot comment from a previous run.

[getsantry]

This pull request has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you add the label WIP, I will leave it alone unless WIP is removed ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

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

[cursor]

Test missing database access decorator

Medium Severity

test_process_message_invalid_recording_json still reaches decompress_segment, which now calls options.get before inflating the body. Valid headers plus an invalid payload (b"t") take that path, so without @django_db_all the options lookup hits the database blocker and the test errors. The same decorator was added to other tests on this path, but this one was missed.

 

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