fix(replay): Skip buffer-mode replay capture when rate-limited (DART-313) - #5813
fix(replay): Skip buffer-mode replay capture when rate-limited (DART-313)#5813runningcode wants to merge 2 commits into
Conversation
…313) In buffer (on-error) mode the recorder keeps running while rate-limited so the rolling buffer stays warm, but capturing on an error still encoded the current and buffered segments and handed them to the transport, which then dropped them. That wasted CPU, I/O, and MediaMuxer file descriptors on envelopes that could never be sent. Bail out of BufferCaptureStrategy.captureReplay when the Replay (or All) category is rate-limited, mirroring the guard session mode already applies. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
📲 Install BuildsAndroid
|
Performance metrics 🚀
|
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| eb95ded | 317.51 ms | 369.08 ms | 51.57 ms |
| 2124a46 | 319.19 ms | 415.04 ms | 95.85 ms |
| c3ee041 | 310.64 ms | 361.90 ms | 51.26 ms |
| dcc6bbf | 382.58 ms | 462.13 ms | 79.54 ms |
| 7a19fee | 315.46 ms | 368.62 ms | 53.16 ms |
| 9054d65 | 330.94 ms | 403.24 ms | 72.30 ms |
| d500866 | 326.13 ms | 378.70 ms | 52.58 ms |
| ad8da22 | 365.86 ms | 427.00 ms | 61.14 ms |
| ed33deb | 337.52 ms | 484.06 ms | 146.54 ms |
| d15471f | 310.26 ms | 377.04 ms | 66.78 ms |
App size
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| eb95ded | 0 B | 0 B | 0 B |
| 2124a46 | 1.58 MiB | 2.12 MiB | 551.51 KiB |
| c3ee041 | 0 B | 0 B | 0 B |
| dcc6bbf | 1.58 MiB | 2.12 MiB | 553.10 KiB |
| 7a19fee | 0 B | 0 B | 0 B |
| 9054d65 | 1.58 MiB | 2.29 MiB | 723.38 KiB |
| d500866 | 0 B | 0 B | 0 B |
| ad8da22 | 1.58 MiB | 2.29 MiB | 719.83 KiB |
| ed33deb | 1.58 MiB | 2.13 MiB | 559.52 KiB |
| d15471f | 1.58 MiB | 2.13 MiB | 559.54 KiB |
| } | ||
|
|
||
| override fun captureReplay(isTerminating: Boolean, onSegmentSent: (Date) -> Unit) { | ||
| if (isReplayRateLimited()) { |
There was a problem hiding this comment.
h: I think we're calling this a bit early -- should likely do it after the if (isTerminating) check, otherwise we'd be dropping replays for crashed events (which are anyway not being sent in this process, but only on next launch, where the rate limit likely will have already been lifted).
Another side effect of not setting isTerminating would be that the following convert() call would convert to session mode and try to keep recording while the process is terminating. Probs, needs a test for this to not regress in the future too
| // the segment envelopes would be dropped by the transport anyway, so don't waste resources | ||
| // encoding videos that will only be discarded | ||
| options.logger.log(INFO, "Replay is rate-limited, not capturing for event") | ||
| return |
There was a problem hiding this comment.
m: another thing -- previously we'd record a client report with the reason ratelimit_backoff on the envelope being dropped, but now we're not doing it. I think after addressing the point above (moving this to after if (isTerminating), we could also record the ratelimit_backoff client report for a genuinely lost event (which would be also called after sampling) inside the if (isReplayRateLimited()) block.
romtsn
left a comment
romtsn
left a comment
There was a problem hiding this comment.
pre-approving, but 2 things I'd want to have addressed
2 participants
📜 Description
In buffer (on-error) session replay mode, the recorder intentionally keeps running while the SDK is rate-limited so the rolling buffer stays warm. However, when an error triggered
captureReplay, the strategy still encoded the current segment and every buffered segment and handed the resulting envelopes to the transport — which then discarded them because of the active rate limit. That wasted CPU, disk I/O, andMediaMuxerfile descriptors on replays that could never be sent.This adds a guard at the top of
BufferCaptureStrategy.captureReplay: if theReplay(orAll) data category is rate-limited, we skip encoding and capturing entirely. This mirrors the guard session mode already applies viaonRateLimitChanged/checkCanRecord. The buffer keeps rolling cheaply in the background and captures normally once the rate limit expires.💡 Motivation and Context
Follow-up to the session replay resource-leak work in #5583 and #5607. Those fixed the
MediaMuxerFD leak during encoding; this closes the remaining item called out in getsentry/sentry-dart#3528 (getsentry/sentry-dart#3528): while rate-limited, the Android SDK kept creating and encoding segments that were only going to be discarded.💚 How did you test it?
Added a unit test (
captureReplay does nothing when rate-limited) asserting that, even with a buffered segment present, no segment is sent to the transport and noreplayIdis written to the scope while rate-limited.📝 Checklist
sendDefaultPIIis enabled.🔮 Next steps
Optionally extend the same guard to the
pauseandonConfigurationChangedencode paths in buffer mode if that churn proves significant.