-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(browser): Add browserSessionIntegration
#14551
Changes from all commits
98db1ca
2a0986e
02cd633
816692e
3781003
d1fa96a
40cefac
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
import { addHistoryInstrumentationHandler } from '@sentry-internal/browser-utils'; | ||
import { captureSession, defineIntegration, logger, startSession } from '@sentry/core'; | ||
import { DEBUG_BUILD } from '../debug-build'; | ||
import { WINDOW } from '../helpers'; | ||
|
||
/** | ||
* When added, automatically creates sessions which allow you to track adoption and crashes (crash free rate) in your Releases in Sentry. | ||
* More information: https://docs.sentry.io/product/releases/health/ | ||
* | ||
* Note: In order for session tracking to work, you need to set up Releases: https://docs.sentry.io/product/releases/ | ||
*/ | ||
export const browserSessionIntegration = defineIntegration(() => { | ||
return { | ||
name: 'BrowserSession', | ||
setupOnce() { | ||
if (typeof WINDOW.document === 'undefined') { | ||
DEBUG_BUILD && | ||
logger.warn('Using the `browserSessionIntegration` in non-browser environments is not supported.'); | ||
return; | ||
} | ||
|
||
// The session duration for browser sessions does not track a meaningful | ||
// concept that can be used as a metric. | ||
// Automatically captured sessions are akin to page views, and thus we | ||
// discard their duration. | ||
startSession({ ignoreDuration: true }); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we adjust the Then again all of this is kind of global, so maybe this does not help anyhow 🤔 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I had the same thoughts. I am actually extremely unsure on how to proceed. It all depends on how we would want sessions to work. If we want there to be multiple at once, it would make sense, however I would err towards the exact opposite. I think always only having one session active per page makes the most sense. Even in MFEs. I would even go so far to lock down the API down even more in v9, simply because it makes wrapping your head around the concept easier. All of this is just thinking out loud though. In general I didn't want this PR to be behaviorally significant. That's why I chose this route. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this makes sense to me! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree, let's leave it at one "global" session per page. |
||
captureSession(); | ||
|
||
// We want to create a session for every navigation as well | ||
addHistoryInstrumentationHandler(({ from, to }) => { | ||
// Don't create an additional session for the initial route or if the location did not change | ||
if (from !== undefined && from !== to) { | ||
startSession({ ignoreDuration: true }); | ||
captureSession(); | ||
} | ||
}); | ||
}, | ||
}; | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
l: any reason to loosen the assertions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally found it to be very annoying that the ordering needed to be exact. Lmk if you want me to change it back.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah I see, the ordering is annoying, agreed. Though these tests wouldn't fail additionally added integrations, unless I'm completely missing something. So that opens the test up to more behaviour change than previously. I don't think this is the end of the world but it'd be good to have at least one test that fails if we add a new integration by default. We should be aware of stuff like this.