feat(browser): Add persisted session lifecycle to browserSessionIntegration - #23446
Draft
logaretm wants to merge 2 commits into
Draft
feat(browser): Add persisted session lifecycle to browserSessionIntegration#23446logaretm wants to merge 2 commits into
session lifecycle to browserSessionIntegration#23446logaretm wants to merge 2 commits into
Conversation
…egration Adds `lifecycle: 'session'`, under which one session spans the user's whole visit: it is persisted in `sessionStorage`, resumed on the next page load, and rotated once it idles out (30 min) or hits its max duration (8 h). Both bounds are configurable via `idleTimeout` and `maxDuration`. `'page'` and `'route'` keep their existing behaviour and `'page'` stays the default, so nothing changes unless the new lifecycle is opted into.
Contributor
size-limit report 📦
|
Lms24
reviewed
Aug 18, 2026
Lms24
left a comment
Lms24
left a comment
Member
There was a problem hiding this comment.
Nice!
For post-hackweek: I'm wondering if we need the idling logic or if we could hard-cap sessions at a lower max time instead. Say, 1-2hrs? No objections in general to this other than bundle size concerns. Absolutely happy to hear more opinions on this :)
Member
Author
I think idling is valuable to filter out garbage telemetry, for example a polling fetch or something that keeps working in the background could flood the session with telemetry and keep it alive while containing no valuable telemetry pertaining to user interaction. A lower max time fixes that tho. I don't have a strong opinion, just something I wanted to surface and discuss. It is not exactly what I wanted tbh, I wanted to introduce idle "gaps" or "pause" a session if that makes any sense. Also happy to drop it to not over complicate things that aren't fully understood. |
`endSession` is now exported from `@sentry/browser` rather than re-exported from core. Calling it ends the current session and immediately starts a new one, so telemetry emitted after the call is attributed to the new session instead of to nothing. Expiry, navigation in the `route` lifecycle, and `endSession` all go through the same rotate step, which under the `session` lifecycle also replaces the `sessionStorage` record so the ended session is not resumed on the next page load.
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.
Adds
lifecycle: 'session'tobrowserSessionIntegration, under which one session spans the user's whole visit: persisted insessionStorage, resumed on the next page load, rotated once it idles out (30 min) or hits its max duration (8 h). Both bounds are configurable.Stacked on #23442. That PR attaches
session.idto telemetry, but today's session is really a page-view id, so a reload mid-checkout looks like several unrelated sessions.'page'and'route'are untouched and'page'stays the default. Opt-in because resuming passesinit: false, so crash-free rate here measures sessions rather than page views. Flipping the default is a separate call.previous_idchaining, naming and outcomes are follow-ups.