Skip to content
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

[Replay]: Remove replayId tag #11618

Open
bruno-garcia opened this issue Apr 15, 2024 · 8 comments
Open

[Replay]: Remove replayId tag #11618

bruno-garcia opened this issue Apr 15, 2024 · 8 comments

Comments

@bruno-garcia
Copy link
Member

bruno-garcia commented Apr 15, 2024

Relay automatically adds replay_id to contexts:

This should be enough for the product to link an error to a replay.

We should be able to remove this code now:

// Tag errors if it has been sampled in buffer mode, or if it is session mode
// Only tag transactions if in session mode
const shouldTagReplayId = isErrorEventSampled || replay.recordingMode === 'session';
if (shouldTagReplayId) {
event.tags = { ...event.tags, replayId: replay.getSessionId() };
}

Blocked by getsentry/sentry#68950

Worth noting that because this requires a fix that's being done in Sentry, this change will regress the experience of replays on Self Hosted Sentry that doesnt' include this version. So we might want to postpone adding this for a while.

@JoshFerge
Copy link
Member

getsentry/sentry#68950 now merged, this work is no longer blocked. should be replay.id everywhere

@AbhiPrasad
Copy link
Member

what minimum self-hosted version does this require? We can sneak the change into v8!

@bruno-garcia
Copy link
Member Author

@mydea said: the self hosted version required by v8 will contain this change (since it's from April). So it's fine for us to remove the tag now on any v8 release.

@mydea
Copy link
Member

mydea commented Jun 4, 2024

actually, looking at this, maybe this is not that easy after all 🤔

Just thinking about this: Today, when an error happens, in the code linked above (handleGlobalEvent) we make the sampling decision for replaysOnErrorSampleRate. If this passes, we add the replayId to the event that is being sent.

When the event was successfully sent (in handleAfterSend), we then, if previously we sampled this and the error was successfully sent, convert the replay buffer session and start sending this.

We could now make the sampling decision in handleAfterSend, but in this case the very first error that triggered sampling would not have the replayId tag yet, because only afterwards we started to send this along 🤔

@billyvg
Copy link
Member

billyvg commented Jun 7, 2024

@mydea we could keep a set of error ids if we are in buffer mode, and check against that in handleAfterSend?

@mydea
Copy link
Member

mydea commented Jun 10, 2024

but the error would not have the replay attached on the server then, as at this point we would not attach the replay ID yet (I believe), as from the perspective of the SDK we are still buffering 🤔

@mydea
Copy link
Member

mydea commented Sep 13, 2024

Would we feel badly about closing this issue? IMHO it does not appear too important to me 🤔

@billyvg
Copy link
Member

billyvg commented Sep 17, 2024

Let's clarify the ask for this ticket next sync @mydea, but from what I understand:

  • We can remove the condition replay.recordingMode === "session" here because in this case, we already have the replay id in DSC:
    // Tag errors if it has been sampled in buffer mode, or if it is session mode
    // Only tag transactions if in session mode
    const shouldTagReplayId = isErrorEventSampled || replay.recordingMode === 'session';
    if (shouldTagReplayId) {
    event.tags = { ...event.tags, replayId: replay.getSessionId() };
    }
  • We cannot add replay id in DSC when recordingMode is buffering because it is still waiting for an error to occur before it can even sample
  • If we get an error event and it is sampled for replay, we currently tag it with replayId. I think what we want to do here is remove the tag so that we are not polluting tags as that is generally reserved for users to use (and not for SDKs).

Based on the 3rd point above, I think what we actually want to do is move replay id from tags to context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants