Can't get Sentry to name Replay according to user consistently

jgarplind commented 8 months ago

Is there an existing issue for this?

[X] I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
[X] I have reviewed the documentation https://docs.sentry.io/
[X] I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/browser

SDK Version

7.104.0

Framework Version

18.2.0

Link to Sentry event

No response

SDK Setup

Sentry.init({
  dsn: ...,
  environment: "production,
  integrations: [
    Sentry.browserTracingIntegration(),
    Sentry.replayIntegration(),
  ],
  tracesSampleRate: 1.0,
  replaysSessionSampleRate: 0,
  replaysOnErrorSampleRate: 1.0,
});

Steps to Reproduce

Sentry.init
Sentry.setUser({ id: ... }) (As soon as userid is available, typically within milliseconds or at least seconds)
Cause an error to trigger a Replay (after, say 10 seconds)
See that the Replay is not named with the user info. If IP address allowed, IP is used. If not, "Anonymous user" is the name of the Replay.

Expected Result

User details should decide the name of the Replay.

Actual Result

4: First attempt after removing IP 3: Somehow it worked this one time? 2, 1: Not working again

Ever since, I decided to opt out from setUser altogether since I don't want to rely on flaky behavior.

jgarplind commented 8 months ago

Asked in Discord too a few days ago: https://discord.com/channels/621778831602221064/1213974752708792380

We are using MSAL (Microsoft auth) and perform setUser as soon as their SDK emits a userLoggedIn event.

mydea commented 7 months ago

@billyvg can it be that we are always using the initial user (when we send the first replay segment), or do we take this into consideration if we later send a different user?

billyvg commented 7 months ago

@mydea Nope, we will account for the user on every segment, here's a repro that consistently updates the user in the web app: https://replit.com/@billy56/AthleticRepentantSymbol#src/index.tsx

@jgarplind Can you confirm in browser dev tools / network tab with the request path: /api/<id>/envelope/ that you see the user id in this json block?

jgarplind commented 7 months ago

@billyvg it seems to be included in a field called did, but after a redirect loop slightly later in the flow, that value is no longer present.

It seems reasonable to assume that the value from Sentry.setUser does not persist across back-and-forth navigations to other domains? Perhaps that is obvious in retrospect.

_P.S. All my payloads are either of the type session or client_report, not replay_event as in your sample._

billyvg commented 7 months ago

@jgarplind Yeah going across domains will create 2 separate replays (assuming replay is installed on both).

If you are not seeing a replay_event, then replays is not active.

If your events look something like:

1) replay_event & no user 2) setUser() called 3) NO following replay_events

Then the replay will never be updated with the new user.

jgarplind commented 7 months ago

It's more of a quick back-and-forth (authenticating via redirect to access a certain part of the application). If I understand you correctly that means that before and after the "bounce" on the auth server will be 2 different replays?

As for replays not being active, that makes sense since I have not triggered any errors, and my replaysSessionSampleRate is 0. Still, if I cause an error, a Replay will be available in my Sentry dashboard, so somehow replays "are active", but maybe this is not what it means for a replay to be active?

Semantics aside, I will try to bump my replaysSessionSampleRate to 1 and check again if I can reproduce something more closely to what you shared.

EDIT: ~I still don't see any replay_event despite bumping replaysSessionSampleRate. Now I'm also remembering that I dropped Sentry.browserTracingIntegration() and tracesSampleRate earlier today to avoid hitting the cost ceiling. Are they somehow involved/required? Briefing the docs earlier today, I thought they looked unrelated to replays.~ Actually interacting a bit with the application (🤦) caused some event and replay_event to be generated. I replicated your logic from repl.it and am indeed seeing the expected id.

Conclusion

The issue appears to have been that I ran Sentry.setUser, then had a quick "bounce" on another domain, causing a new Replay to be started, one that is not aware of the user information provided before the bounce. All things considered, it seems like a good idea to set user information every time the web page is launched, not just on the initial, unauthenticated launch.

Thank you a lot for guiding me to these insights. Feel free to close the issue if you are satisfied with the outcome. I will reach out again in the unlikely event that this conclusion is incorrect.

billyvg commented 7 months ago

If it's the same origin and same browser tab, it (by default), should be the same replay as it's bouncing around. I'll close out the issue, feel free to re-open if needed

getsentry / sentry-javascript