feat: attach browser.instance.id and browser.instance.visibility_state to spans
#878
Conversation
|
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
Each span now includes `browser.instance.id`, a unique ID shared across all same-origin frames/contexts within the browser tab. This ID persists across tab reloads until the tab is closed or a different origin is loaded. Additionally, `browser.instance.visibility_state` is added to each span to indicate the tab's visibility state (hidden/visible) at the time the span was created.
|
I have read the CLA Document and I hereby sign the CLA |
packages/web/src/utils/storage.ts
Outdated
| export const safelyGetSessionStorage = (key: string): string | null => { | ||
| let value = null; | ||
| try { | ||
| value = window.sessionStorage.getItem(key); |
There was a problem hiding this comment.
okay on the topic of session storage I don't have any strong feelings either way and it seems alright but following MDN's docs:
survives over page reloads and restores.
Page reloads I think we can accept because they'll come up in spans. Restores seem like a rare case. So I think this is okayish?
Duplicating a tab copies the tab's sessionStorage into the new tab.
Not sure about this one but it also seems rare enough?
I think we can just deploy this and check if it's good enough in practice.
There was a problem hiding this comment.
survives over page reloads and restores
I did it intentionally that way. It is representing the browser tab rather than just the current window. I mean it can be adjusted if needed.
Duplicating a tab copies the tab's sessionStorage into the new tab.
I guess it is the same as the "restore" case. In the Cisco agent, we cover these use cases, but it requires a bigger refactor as the initialization would need to be asynchronous, and we would need to postpone span sending until the ID is assigned. It can be built on top of this as it is just an additional improvement.
| safelySetSessionStorage(BROWSER_INSTANCE_ID_KEY, browserInstanceId); | ||
| } | ||
|
|
||
| this._id = browserInstanceId; |
There was a problem hiding this comment.
if we didn't manage to persist it then wouldn't it be better to not attach it to spans? Because now let's say someone blocks session storage, and we see their session, it'll have a different browser.instance.id for each scriptInstance, tricking you into believing that these are separate windows.
There was a problem hiding this comment.
Good point. Please check 861bed8
| @@ -47,6 +47,7 @@ export class SplunkSpanAttributesProcessor implements SpanProcessor { | |||
| span.setAttribute('location.href', location.href); | |||
| span.setAttributes(this._globalAttributes); | |||
| span.setAttribute('splunk.rumSessionId', getRumSessionId()); | |||
| span.setAttribute('browser.instance.visibility_state', document.visibilityState); | |||
There was a problem hiding this comment.
We can now filter how many sessions consist of only long tasks in a hidden state.
Description
Each span now includes
browser.instance.id, a unique ID shared across all same-origin frames/contexts within the browser tab. This ID persists across tab reloads until the tab is closed or a different origin is loaded. Additionally,browser.instance.visibility_stateis added to each span to indicate the tab's visibility state (hidden/visible) at the time the span was created.Type of change
Delete options that are not relevant.
How has this been tested?
Delete options that are not relevant.