Conversation
Contributor
size-limit report 📦
|
mydea
reviewed
Jul 15, 2025
|
|
||
| // Make sure to reset `recordingMode` to `buffer` to avoid any additional | ||
| // breadcrumbs to trigger a flush (e.g. in `addUpdate()`) | ||
| this.recordingMode = 'buffer'; |
Member
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...?
Member
Author
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.
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.
billyvg
force-pushed
the
billy/replay-437-buffered-replays-are-being-captured-with-no-linked-errors
branch
from
7d56b74 to
5b50623
Compare
🚨 BugBot couldn't runSomething went wrong. Try again by commenting "bugbot run", or contact support (requestId: serverGenReqId_1e626e96-09a2-4040-a16f-f9d879f4e286). |
chargome
approved these changes
Jul 17, 2025
…ng-captured-with-no-linked-errors
billyvg
deleted the
billy/replay-437-buffered-replays-are-being-captured-with-no-linked-errors
branch
billyvg
added a commit
that referenced
this pull request
Jul 28, 2025
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()`](https://github.com/getsentry/sentry-javascript/blob/develop/packages/replay-internal/src/coreHandlers/util/addBreadcrumbEvent.ts#L9) is called which then calls [`triggerUserActivity()`](https://github.com/getsentry/sentry-javascript/blob/develop/packages/replay-internal/src/coreHandlers/util/addBreadcrumbEvent.ts#L15) 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](https://github.com/getsentry/sentry-javascript/blob/develop/packages/replay-internal/src/replay.ts#L917-L918). 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 because we only check that [`recordingMode` is `buffer](https://github.com/getsentry/sentry-javascript/blob/develop/packages/replay-internal/src/replay.ts#L626)`. ## Solution When we call `stop()`, reset the `recordingMode` to `buffer` (this should be safe default as it is more restrictive behaviorally than `session`) and in `addUpdate`, add a check to see if `isEnabled()` is true (recording is enabled).
AbhiPrasad
added a commit
that referenced
this pull request
Jul 29, 2025
This is the v9 backport of #17008, which 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. Co-authored-by: Abhijeet Prasad <aprasad@sentry.io>
This was referenced Sep 29, 2025
This was referenced Oct 7, 2025
This was referenced Oct 15, 2025
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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).