Problem Statement

Currently, browserSessionIntegration has two lifecycle modes:

• route (default): Starts a new session on every route change by listening to the history API
• page starts a new session on every pageload that persists across soft navigation/route changes.

route was always the default but it doesn't align well with how users reason about sessions (way too short).

Solution Brainstorm

• We flip the default to page to get a more accurate (albeit not perfect) representation as the default model
• Users can still fall back to route if this better suits their understanding of a session

Additional Context

Benefits

• better mental model alignment of a session by default
• sets us up for assigning a session id to telemetry
• old model still available (the bundle size tax is minimal so I'd argue we keep it around)

Drawbacks/Implications

• Can impact users' release health metrics (alerts, dashboards, etc) because once we flip the mode, the SDK will send significantly less sessions for SPA applications
  • Mitigation 1: We only ship it this in a major, call it out in the migration docs and justify it. I'd classify this as a behaviour breaking change.
  • Mitigation 2: Users can fall back to route-based lifecycle which lets them opt out of the behaviour change

Future work

• Add a third mode ("sessionstorage" or "tab") which extends the session to the browser's sessionStorage lifetime.
  • tracked in Allow use of sessionStorage in browserSessionIntegration to more accurately count sessions for MPAs #14478
  • can only be opt-in due to cookie/storage banner requirements when an app writes to a browser storage
  • needs alignment/synchronization with replay session if replay is enabled

Priority

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.}