feat(replay): Reset replay id from DSC on session expiry/refresh#20129
feat(replay): Reset replay id from DSC on session expiry/refresh#20129billyvg wants to merge 4 commits intogetsentry:developfrom
Conversation
Its possible that a user returns to an old Sentry tab, an error gets thrown and ingested w/ the expired replay id in DSC. This error then gets link in our UI because of the replay id in DSC and causes the duration to appear to be very long (>>> 1 hr). This PR adds a check in handleGlobalEvent to clear the replay id from DSC if the replay session is expired. It also updates the DSC when in session mode and replay session is refreshed.
|
This PR has been automatically closed. All non-maintainer contributions must reference an existing GitHub issue. Next steps:
Please review our contributing guidelines for more details. |
Semver Impact of This PR🟡 Minor (new features) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨Core
Deps
Other
Bug Fixes 🐛Core
Other
Internal Changes 🔧Core
Deps
Other
🤖 This preview updates automatically when you update the PR. |
|
folks lets remove whatever behavior is auto closing PRs this is a waste of our time for what purpose? if you want to auto close stuff it should be on a real heuristic, not just because someone didnt add boilerplate work to create ani ssue first |
|
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 apply the label |
| SESSION_IDLE_EXPIRE_DURATION, | ||
| SESSION_IDLE_PAUSE_DURATION, |
There was a problem hiding this comment.
lint: Those are unused, should address lint warnings.
There was a problem hiding this comment.
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.
Reviewed by Cursor Bugbot for commit 2aa9c1e. Configure here.
| }) | ||
| ) { | ||
| resetReplayIdOnDynamicSamplingContext(); | ||
| } |
There was a problem hiding this comment.
Early DSC reset uses stricter expiry than session management
Low Severity
The early check uses isSessionExpired to decide whether to clear replay_id from DSC, but the downstream checkAndHandleExpiredSession → _checkSession uses shouldRefreshSession, which has an additional carve-out: it returns false for buffer-mode sessions with segmentId === 0 even when isSessionExpired returns true. This means for a time-expired buffer session that hasn't flushed, the early check removes replay_id from DSC, but checkAndHandleExpiredSession still treats the session as active and tags the error event with replayId. Furthermore, sendBufferedReplayOrFlush calls startRecording() without calling setReplayIdOnDynamicSamplingContext, so the DSC stays without replay_id even after converting to session mode.
Reviewed by Cursor Bugbot for commit 2aa9c1e. Configure here.
There was a problem hiding this comment.
Hmm this is true I think -- will think about this more next week.


Its possible that a user returns to an old Sentry tab, an error gets thrown and ingested w/ the expired replay id in DSC. This error then gets link in our UI because of the replay id in DSC and causes the duration to appear to be very long (>>> 1 hr). This PR adds a check in handleGlobalEvent to clear the replay id from DSC if the replay session is expired.
It also updates the DSC when in session mode and replay session is refreshed.