Initialising Sentry multiple times with Browser Tracing enabled

[joerayme]

• [x] Review the documentation: https://docs.sentry.io/
• [x] Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• [x] Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• [ ] Provide a link to the affected event from your Sentry account

Package + Version

• [x] @sentry/browser
• [ ] @sentry/node
• [ ] raven-js
• [ ] raven-node (raven for node)
• [ ] other:

Version:

6.4.0

Description

We're running into a couple of problems when initialising Sentry multiple times on the same page. According to #3332 that should be possible but the problems we're seeing are:

• Whenever a new client is initialised, the instrumentation that sends tracing/performance information is re-added which means you end up with more and more traces for the same page view (one for each time the client has been initialised)
• The first transaction is always a pageload (I think because of these lines) and always includes everything that's happened since the initial page was loaded rather than just the things since the last navigation event.

I've set up a repro in this repository, hopefully it shows the problem well enough. Happy to provide example traces in Sentry using the repro apps if needed.

I understand this is probably a bit of an edge case but I'm interested to know whether it's something that Sentry thinks it should be supporting given the comments on #3332. For the time being we're going to try and circumvent the issue by moving the Sentry initialisation into the 'app shell' code but this does mean that everything will appear under one project in Sentry and it will be more difficult to implement app-specific config.

[lobsterkatie]

I think what you're seeing makes sense, given the way the SDK is set up, but I want to confirm one thing: when you say "you end up with more and more traces for the same page view," are you talking about the pageload transactions you mentioned in the second bullet (which I would expect), or is this happening with navigation transactions also (which I would not expect)?

In any case, if the same Sentry instance is always the first to load, try using the startTransactionOnPageLoad option documented here to have that instance collect your pageload trace and all the other instances not do so. If you don't know which instance will load first, you could always have whichever one loads first set a flag on window which every instance would check before enabling this option.

If that doesn't work, there are hackier ways to hack it, but let's try the simple option first.

[joerayme]

Thanks Katie. You're right that it only adds extra calls to Sentry on 'pageload' transactions, not navigations. I've added that case to the repro apps.

Using startTransactionOnPageLoad is an interesting solution but from testing in the repro app it seems that only prevents the duplicate event being sent on the first transaction in the new app; subsequent navigations still have the duplicate events. I've added that as a test case in the repro app (see the startTransactionOnPageLoad branch).

We've managed to solve it for now by only initialising the Sentry client in the app shell which is mostly OK but it's a bit of a brittle solution (if there's a deviation in Hub versions between apps then it breaks monitoring completely) and it does mean we can't implement app-specific config as easily so it would be nice to have a better way around it.

[joerayme]

Also one major downside of initialising Sentry only in the app shell is that I think parameterised React routes will never get grouped together because that relies on a variable set by the React Router instrumentation.

[HazAT]

Sorry, this will probably never work in that way - multiple instances of Sentry on the page is not our main prio right now.