Remix: Sentry conflict with Remix's Error Boundaries

[dmarkow]

Is there an existing issue for this?

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

How do you use Sentry?

Sentry Saas (sentry.io)

Which package are you using?

@sentry/remix

SDK Version

7.13.0

Framework Version

React 18.2.0 / Remix 1.7.1

Link to Sentry event

No response

Steps to Reproduce

Set up a new Remix app and add Sentry. Add an ErrorBoundary export to the root file:

// app/root.tsx

// ...

export const ErrorBoundary: ErrorBoundaryComponent = () => {
  return <div>REMIX BOUNDARY</div>;
}

function App() {
  // ...
}

export default withSentry(App, {
  wrapWithErrorBoundary: true,
  errorBoundaryOptions: {
    fallback: <div>SENTRY BOUNDARY</div>;
  }
})

Expected Result

I should be able to use Remix's own ErrorBoundary functionality both at the root level and in child routes and still have Sentry know when/when not to report errors.

Alternatively, if there are limitations in Remix that won't let this work as expected, the documentation should be clearer about server/client error handling and error boundaries.

Actual Result

The custom "REMIX BOUNDARY" ErrorBoundary above only gets displayed if the error was server side. All client-side errors use the "SENTRY BOUNDARY" error set in withSentry (unless you have a route-level ErrorBoundary, then client-side errors never make it to Sentry. My guess is that the withSentry fallback/wrapper completely ignores all server-side errors to avoid double-reporting.)There are a bunch of combinations of server/client errors and server/client rendering (I'm sure I'm missing some):

• SSR/CSR loader/action error: Sentry reports this server-side and does not report it client-side. The Remix boundary is displayed. If I remove the Remix boundary export, a raw error trace is rendered. Sentry's fallback is never displayed.
• CSR rendering error: Sentry reports the error and the Sentry fallback is displayed. The Remix boundary is not shown.
• SSR rendering error: Sentry reports the error server-side. Same result client-side as the loader/action errors in the first bullet above.

If I add a custom Remix ErrorBoundary export to a child route, the behavior is the same with one exception:

• CSR rendering error: Sentry does not report any error and the Remix boundary is shown. This seems to be the most common spot for errors to go unreported.

It seems the only viable solution until this is addressed is:

• Add a root-level Remix error boundary AND a custom fallback to Sentry that are essentially duplicates of each other so you get consistent error screens.
• Don't use route-level error boundaries (which goes against the whole point of Remix's nested route handling), or if you do, manually call Sentry.captureException(...) in them, though that could possibly report duplicate issues from both the server and client side.

[onurtemizkan]

Thanks for reporting this, @dmarkow!
I'll post an update here after checking how we can resolve this.

[onurtemizkan]

I have checked both Sentry and Remix implementations of ErrorBoundary. Remix implementation has a wider scope and includes errors thrown from actions and loaders, which we instrument on build, and are out of Sentry's ErrorBoundary scope (Sentry's ErrorBoundary is implemented in @sentry/react SDK and specifically for client-side errors).

• SSR/CSR loader/action error: Sentry reports this server-side and does not report it client-side. The Remix boundary is displayed. If I remove the Remix boundary export, a raw error trace is rendered. Sentry's fallback is never displayed.

This is expected behaviour of the current implementation. Sentry's fallback is only responsible for the client-side React errors.

---

• CSR rendering error: Sentry reports the error, and the Sentry fallback is displayed. The Remix boundary is not shown.

I agree that this should be handled consistently.

---

• SSR rendering error: Sentry reports the error server-side. Same result client-side as the loader/action errors in the first bullet above.

This is also the expected behaviour.

---

So, looks to me, we could just stop wrapping the whole application with Sentry's ErrorBoundary, and find a way to instrument Remix's ErrorBoundary (and CatchBoundary too?). So, we can avoid inconsistent fallback screens.

• CSR rendering error: Sentry does not report any error, and the Remix boundary is shown. This seems to be the most common spot for errors to go unreported.

This is a bug I could reproduce. I haven't debugged it further, but if we can do instrumentation aimed at ErrorBoundary functions of every route, it will probably be solved.

But that may not be too easy, because when I tried to wrap ErrorBoundary in instrumentBuild, I was able to instrument the server-side ErrorBoundary but not the client-side one.

So, we are dealing with two copies of builds, one from remix-server-core and one from remix-react. Not sure we can patch remix-react as we do with remix-server-core. But maybe worth a try, perhaps?

cc: @AbhiPrasad

[AbhiPrasad]

But that may not be too easy, because when I tried to wrap ErrorBoundary in instrumentBuild, I was able to instrument the server-side ErrorBoundary but not the client-side one.

We could do this - for client side error boundaries, users have to opt-in and wrap things themselves. We can provide the necessary helpers for that. We then automatically wrap the server-side errors boundaries. Not sure about this though.

For sure we should address this bug though - and I think changing the behaviour is fine, we can update the docs. @onurtemizkan could you start taking a look at this? I think it's worth a try to explore this.

[onurtemizkan]

I have experimented this a bit, and it looks like we could just switch to opt-in all together server and client by providing a wrapper utility and eliminating @sentry/react's ErrorBoundary.

Remix's ErrorBoundary covers everything that our React ErrorBoundary does and more. So wrapping it, we can report every error that appears into it, and leave the rendering of fallback pages to Remix. That would resolve all inconsistencies, and unreported errors. Also, by making this opt-in, we may give users flexibility to not report errors for a specific route. (if that error doesn't fall back to the root error handler).

One problem that may occur is if there is no ErrorBoundary defined for root, we will miss the React errors. We can add it to docs to remind users to create (and wrap) their root ErrorBoundarys.

The other problem is that we wouldn't know if the error is from server or client, so it will be hard to categorise them. We can add a new op like remix.boundary.*, but we'll need to check if they are deduped first, as we already report server-side errors.

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀