fix(browser): Ensure user id is consistently added to sessions#19341
Open
fix(browser): Ensure user id is consistently added to sessions#19341
Conversation
Contributor
Codecov Results 📊Generated by Codecov Action |
Contributor
size-limit report 📦
|
Contributor
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
Sentry.setUser callsThere 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.
| isolationScope.addScopeListener(scope => { | ||
| const maybeNewUser = scope.getUser(); | ||
| // sessions only care about user id and ip address, so we only need to capture the session if the user has changed | ||
| if (previousUser?.id !== maybeNewUser?.id || previousUser?.ip_address !== maybeNewUser?.ip_address) { |
There was a problem hiding this comment.
Scope listener misses user changes with only email/username
Medium Severity
The scope listener condition only checks previousUser?.id and previousUser?.ip_address for changes, but updateSession in session.ts derives the session did from context.user.id || context.user.email || context.user.username. If Sentry.setUser({ email: 'test@test.com' }) is called without an id or ip_address, the listener won't detect the change (both comparisons evaluate to undefined !== undefined → false), so captureSession() is never called. The session internally has the did set, but the update is never sent to Sentry. The comment "sessions only care about user id and ip address" doesn't match the actual did derivation logic.
Member
Author
There was a problem hiding this comment.
That's intentional. The only fields picked from the user are the id and the ip_address (if ever set in the browser). So we only need to watch these for changes.
3 tasks
JPeer264
approved these changes
Feb 16, 2026
|
|
||
| Previously, the SDK inconsistently set the user id on sessions, meaning sessions were often lacking proper coupling to the user set for example via `Sentry.setUser()`. | ||
| Additionally, the SDK incorrectly skipped starting a new session for the first soft navigation after the pageload. | ||
| This patch fixes these issues. As a result, metrics around sessions, like "Crash Ffree Sessions" or "Crash Free Users" might change. |
Member
There was a problem hiding this comment.
m:
Suggested change
| This patch fixes these issues. As a result, metrics around sessions, like "Crash Ffree Sessions" or "Crash Free Users" might change. | |
| This patch fixes these issues. As a result, metrics around sessions, like "Crash Free Sessions" or "Crash Free Users" might change. |
|
|
||
| While we're at it, if you're using Sentry in a Single Page App or meta framework, you might want to give the new `'page'` session lifecycle a try! | ||
| This new mode no longer creates a session per soft navigation but continues the initial session until the next hard page refresh. | ||
| Check out the [docs](TODO LINK) to learn more! |
Member
There was a problem hiding this comment.
l: Just a reminder to not forget to set the link in the docs
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
2 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 PR fixes multiple bugs and problems around browser sessions, mostly related to user id assignment:
When calling
Sentry.setUser()on static pages (i.e. no soft navigations), the user id would never be added to sessions. This is because in static pages, we don't send an"exited"session update. The fix: We send a session update whenever the user is set on the isolationScope (see comment about limitations)When calling
Sentry.setUser()in a single page application (i.e. with soft navigations), we would update the initial session with the user data when starting a new session for a new navigation. However, we did not include the user id on the new session, because thegetCurrentScope().getUser() || getIsolationScope().getUser()check was flawed. The fix: we use ourgetCombinedScopeDatahelper to get the "correct" (read, consistently like in other telemetry items) user.It seems like we had an incorrect check that would skip creating a new sessions for the first soft navigation after the pageload (in the default
'route') session lifecycle. The fix: We no longer check forfrombeing undefined.In addition, I also added a new
waitForSessionhelper and refactored most session integration tests to use this helper. This allows us to more granularly listen to multiple session envelopes simultaneously without running into collision risks.As a result of these fixes, session counts could increase as a whole but also metrics like "crash free users" will likely change. I added a note to the changelog calling this out.
closes #19317