feat(browser): Add mode option for the browser session integration#18997
feat(browser): Add mode option for the browser session integration#18997
Conversation
JPeer264
force-pushed
the
jp/browser-session-mode
branch
from
6dae52a to
85aa5da
Compare
size-limit report 📦
|
JPeer264
force-pushed
the
jp/browser-session-mode
branch
from
c45eae4 to
452d0c4
Compare
| * | ||
| * @default 'navigation' | ||
| */ | ||
| mode?: 'single' | 'navigation'; |
There was a problem hiding this comment.
I am not 100% sure about the naming here, as it's only clear when reading the JS doc. A suggestion:
sessionMode: 'navigation' | 'only-pageload'Hm, now that I think more about it, it's probably fine because this is an option in the browserSessionIntegration and it should be clear that this is about the session. So the naming would actually work already (just leaving this to share my thoughts).
There was a problem hiding this comment.
uuuuuuh, I actually like only-pageload. However, it seems too technical correct - it could be that "only-pageload" implies that it doesn't track the session further 🤔
@Lms24 wdyt? To get a third opinion here :)
There was a problem hiding this comment.
hmm yeah, "only-pageload" to me also implies something like "we only track sessions for the pageload and stop afterwards".
Let's think about this, also from a perspective of potentially adding a third mode for persisting the id in sessionStorage in the future. So mentally, it should correlate to "short -> medium -> long".
How about:
lifecycle: 'route' | 'page' | 'tab'lifecycle: 'navigation' | 'pageload' | 'tab'
1 has the advantage that it's very descriptive, but confusion could come from "page". I think this is minimal and also kinda works anyway because it's primarily relevant for Single Page applications".
2 is a bit more technical but correlates well with established Sentry terms.
I think with the proper JSDoc (which is already there xD), both would work well. Especially if we pair these with lifecycle since this more directly implies session life time than "mode" IMHO. Fully realizing I said other things offline, so sorry for throwing yet more options into the ring. Thoughts?
fwiw, Gemini clearly prefers 1 😅
There was a problem hiding this comment.
I gave it now one week of thought. Tbh lifecycle is indeed better. Also because we use lifecycle already in our codebase for such scenarios (e.g. profileLifecycle).
I also thought about naming, I think there is no perfect solution/wording for this one I'm afraid. Let's go for Option 1 of your newest suggestion and see where it leads to.
| await page.locator('#navigate').click(); | ||
|
|
||
| const sessions = (await sessionsPromise).filter(session => session.init); | ||
|
|
||
| expect(sessions.length).toBe(1); |
There was a problem hiding this comment.
l: What I like to do when I test that something is not sent, is to await an event after navigating so that we have some time before ending the tests. I guess in this case, we could wait for an error or a transaction event. There's still an assumption here that the session would have been sent before that event but I think that's reasonable and better than not waiting at all or waiting for a a specific time.
We could even make it more deterministic by:
- going to the page
- awaiting for the init session
- registering the request listener for additional sessions
- navigating
- waiting for the unrelated event
- asserting that no more session envelopes have been sent
There was a problem hiding this comment.
Those are very valid points. I'll try to implement these
| * | ||
| * @default 'navigation' | ||
| */ | ||
| mode?: 'single' | 'navigation'; |
There was a problem hiding this comment.
hmm yeah, "only-pageload" to me also implies something like "we only track sessions for the pageload and stop afterwards".
Let's think about this, also from a perspective of potentially adding a third mode for persisting the id in sessionStorage in the future. So mentally, it should correlate to "short -> medium -> long".
How about:
lifecycle: 'route' | 'page' | 'tab'lifecycle: 'navigation' | 'pageload' | 'tab'
1 has the advantage that it's very descriptive, but confusion could come from "page". I think this is minimal and also kinda works anyway because it's primarily relevant for Single Page applications".
2 is a bit more technical but correlates well with established Sentry terms.
I think with the proper JSDoc (which is already there xD), both would work well. Especially if we pair these with lifecycle since this more directly implies session life time than "mode" IMHO. Fully realizing I said other things offline, so sorry for throwing yet more options into the ring. Thoughts?
fwiw, Gemini clearly prefers 1 😅
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There 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.
dev-packages/browser-integration-tests/suites/sessions/route-lifecycle/test.ts
Outdated
Show resolved
Hide resolved
JPeer264
force-pushed
the
jp/browser-session-mode
branch
from
8307b01 to
be3044b
Compare
JPeer264
force-pushed
the
jp/browser-session-mode
branch
from
be3044b to
2484c0f
Compare
Codecov Results 📊Generated by Codecov Action |
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.
|
3 participants
closes #18921
closes JS-1526
This adds a new
lifecycleoption to theBrowserSessionIntegration.New explained:
The default is to
routeto not introduce any breaking changeMerge checklist