How to handle "unhandled" errors in Micro Frontend Setup

[sagarhani]

Description

The documentation about using Sentry in Micro Frontend Application is great. It works well in catching exceptions (captureException).

However, it doesn't work well for unhandled errors.

For instance, if there is an uncaught exception like throw new Error("oh no!"), or if some error was thrown by a 3rd party package, Sentry fails to determine to which micro frontend app this error belongs, and ends up sending this error event to the FALLBACK_DSN.

Consequently, all uncaught exceptions are reported in the FALLBACK_DSN Sentry project.

How should we handle this situation?

[lforst]

Hi, we're working on a solution for this via our webpack plugin. The docs aren't done yet but you can track the progress here: getsentry/sentry-docs#7558

[sagarhani]

Hey @lforst, 👋

The Sentry Webpack plugin helped in handling the above mentioned case. Thank you. 🙇

However, we are currently encountering this issue:

The error is due to a bug in the 3rd party package. This 3rd party package is loaded by one of the Micro frontend applications (MFE) and the components from this package (it's a shared package) is also consumed by other Micro frontend applications.

Now, MFE-1 loaded this shared 3rd party package hence it contains the injected moduleMetadata as team: 'mfe-1'. But, MFE-2 renders components from this shared package and due to some action in MFE-2 app, error was triggered.
Sentry reported this error to the MFE-1 sentry project.

In reality, the code responsible for this error is in 3rd party package. Just because it was loaded by MFE-1, all errors coming from this 3rd party package is reported to MFE-1 sentry project.

Instead, Is it possible to report the error to MFE sentry project that was responsible(triggered) for the error? (in this case MFE-2 sentry project)
Or any thoughts on how to deal with this case will be helpful. 🙏

[lforst]

Hm, I don't think I fully understand yet what's happening in your project but what I can recommend is looking at the entire stacktrace to extract where somthing originated from. If you want to report to the project that is responsible for throwing you should take the team from the top frame, if you want to report to the project that was calling you should take the team from the bottom frame, does that make sense?

[sagarhani]

If you want to report to the project that is responsible for throwing you should take the team from the top frame, if you want to report to the project that was calling you should take the team from the bottom frame, does that make sense?

Got it, I'm gonna give this a try. 👍
Thank you.