Hi all,

I have a question regarding strategies to initialise Sentry SDK in microfrontends architecture. I have read the corresponding docs section and more, however I still have some open questions, so I hope to obtain some knowledge here.

High level overview of a setup we are working with:

• We have a number of React applications.
• Each app is hosted on a separate route, i.e. org.com/product-a, org.com/product-b, etc.
  • We also have a platform code, which mounts a corresponding React app based on the route.
• Each app has its own Sentry project.

Currently, every React app is calling Sentry.init with its own DSN key when the app is mounted. However, our users can navigate between the products (i.e. go from product A to product B). Since this navigation involves mounting a new MFE, Sentry.init can be called twice.

The documentation linked above states the following:

In all cases Sentry.init() must never be called more than once, doing so will result in undefined behavior.

Thus I was wondering what would be a reasonable Sentry.init strategy in our scenario. We mainly call Sentry.init when a corresponding microfrontend is mounted to ensure that the runtime errors from the newly mounted app are routed to the correct project. (Note: however we are have a significant amount of misrouted issues, i.e. runtime issue from project A report to project B and vice versa).

Is there a way for us to ensure that calling Sentry.init when a new app is mounted would not inflict unknown behaviour? Perhaps something similar to a concept of the useEffect hook in React, where we can return a "cleanup" function. I guess if any sort of "re-initialise" mechanism can be implemented, we could keep calling Sentry.init on app mount.

Alternatively, I imagine we could call Sentry.init once, before any microfrontend app is mounted, and then with custom transport we navigate issues to the corresponding Sentry projects? I wonder if in this scenario we could still benefit from having multiple Sentry projects and if Replays, performance tracing data and other data can be properly distributed between Sentry projects...

Please let me know what you think. I would be happy to hear any inputs on this topic. Thank you!