Remix: Sentry conflict with Remix's Error Boundaries

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]

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.

[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.