fix(replay): Fix re-sampled sessions after a click #17008
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This fixes a bug where an expired session-based replay will always force a new session-based replay after a click, regardless of the actual recording mode. What is happening is: - a session-based replay is left idle - user comes back and clicks on the page and triggers the click listener - `addBreadcrumbEvent()` is called which then calls `triggerUserActivity()` because it is a click - next, `_checkSession()` and `_refreshSession()` are called and this is where the problem starts Inside of `_refreshSession` we stop the current replay (because the session is expired), however `stop()` is async and is `await`-ed before we re-sample. So the current replay state while `stop()` is finishing has: - `recordingMode` = `session` (initial value) - `isEnabled` = false Another however, `addBreadcrumbEvent` (and everything called until `_refreshSession`) are not async and does wait for resampling (`initializeSampling()`) to occur. This means that the click breadcrumb ends up causing a flush and always starting a new replay recording.
size-limit report 📦
|
mydea
reviewed
Jul 15, 2025
| @@ -503,6 +503,10 @@ export class ReplayContainer implements ReplayContainerInterface { | |||
| // enter into an infinite loop when `stop()` is called while flushing. | |||
| this._isEnabled = false; | |||
|
|
|||
| // Make sure to reset `recordingMode` to `buffer` to avoid any additional | |||
| // breadcrumbs to trigger a flush (e.g. in `addUpdate()`) | |||
| this.recordingMode = 'buffer'; | |||
There was a problem hiding this comment.
not sure, do we (need to?) reset this at some point? I guess not, as ended usually means ended for good for us I suppose...?
There was a problem hiding this comment.
We currently don't need to, but I think it's a safer option to have it reset here.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a bug where an expired session-based replay will always force a new session-based replay after a click, regardless of the actual recording mode.
What is happening is:
addBreadcrumbEvent()is called which then callstriggerUserActivity()because it is a click_checkSession()and_refreshSession()are called and this is where the problem startsInside of
_refreshSessionwe stop the current replay (because the session is expired), howeverstop()is async and isawait-ed before we re-sample. So the current replay state whilestop()is finishing has:recordingMode=session(initial value)isEnabled= falseAnother however,
addBreadcrumbEvent(and everything called until_refreshSession) are not async and does wait for resampling (initializeSampling()) to occur. This means that the click breadcrumb ends up causing a flush and always starting a new replay recording because we only check that [recordingModeisbuffer](https://github.com/getsentry/sentry-javascript/blob/develop/packages/replay-internal/src/replay.ts#L626).Solution
When we call
stop(), reset therecordingModetobuffer(this should be safe default as it is more restrictive behaviorally thansession) and inaddUpdate, add a check to see ifisEnabled()is true (recording is enabled).