Issue with error boundary handling with throwing middleware

[VillePakarinenPosti]

Reproduction

Following up on our discussion in #13766 (comment)

I've updated the reproduction to use v7.8.0 — you can check it out here:
👉 https://stackblitz.com/edit/github-ka7tf4zb-fqjd8nkf?file=app%2Froutes%2Findex.tsx

System Info

v7.8.0

Used Package Manager

npm

Expected Behavior

✅ Expected behavior :

• When navigating to a route whose middleware throws and which exports an error boundary, the error should be caught and displayed by that route’s error boundary.

• If no error boundary is defined on that route, the error should propagate up the route hierarchy and be caught by the nearest parent boundary. Such as a layout-level or root-level boundary.

• This behavior should be consistent whether the navigation happens during initial render or after the app has loaded.

Actual Behavior

❌ Unexpected behavior with v7.8.0:

• When navigating to a route with throwing middleware and an exported error boundary, the error is not caught by the route’s boundary.

• Instead, the error bypasses all nested boundaries (including layout-level ones) and is caught by the root error boundary.

[brophdawg11]

There is a small bug here but it's not exactly what you described. I noticed that when commenting out the clientLoader redirect, it was still landing at the root when it shouldn't be - that's fixed in #14150.

This behavior should be consistent whether the navigation happens during initial render or after the app has loaded.

This isn't quite right. When you redirect in a clientLoader during initial load it effectively interrupts the navigation and starts a new one. This means that any other in-progress loaders have to re-run because their results never got committed at the end of the navigation (because it was cancelled by the redirect). In framework mode, even though you don't have an explicit loader/clientLoader on those routes, they have one under the hood because we need to fetch the JS assets and any required CSS for those routes. So the initial-load redirect starts a fresh navigation to /details and that needs to run the internal loader for the layout route again which means we need to bubble to the nearest error boundary at or above that route.

When you navigate via the <Link> after initial load, those loaders do not need tore-run and we can use the details route error boundary.

[github-actions]

🤖 Hello there,

We just published version 7.8.1-pre.0 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

[github-actions]

🤖 Hello there,

We just published version 7.8.1 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

[VillePakarinenPosti]

Thanks again for the quick response! 🙏

In framework mode, even though you don't have an explicit loader/clientLoader on those routes, they have one under the hood because we need to fetch the JS assets and any required CSS for those routes. So the initial-load redirect starts a fresh navigation to /details and that needs to run the internal loader for the layout route again which means we need to bubble to the nearest error boundary at or above that route.

I've got a followup question. Here’s the mock structure I’m working with (framework mode):

routes/
├── _layout.tsx                 # `/` main layout (wraps everything, renders nav etc)
└── $locale/                    # `/:locale`
    ├── home.tsx                # `/:locale/home`
    └── edit/                   # `/:locale/edit`
        ├── operation-1.tsx     # `/:locale/edit/operation-1`
        └── operation-2.tsx     # `/:locale/edit/operation-2`

My goal is to guard everything under /en/edit/* so only privileged users can access sub-routes, while keeping the main layout and navigation structure visible when access is denied. Ideally, throwing inside the edit middleware would let the error boundary in main layout render a 403 message, instead of always bubbling up to the root error boundary.

What is the recommeded approach for this so I could keep the experience consistent with the initial load (all-loaders trigger) and further navigations where only the selected loaders will revalidate.

One workaround I considered was redirecting to /en/permission-denied?from=/en/edit/..., but that breaks active-link matching (the nav no longer highlights the section the user tried to reach). I could ofc keep throwing in every route within /edit/* but that's the exact thing I'm trying to avoid with the middleware setup.

[brophdawg11]

It's hard to say without seeing your routes. Can you open a new Q&A discussion with a small reproduction via https://reactrouter.com/new? I can try to take a look.

[VillePakarinenPosti]

Wrote something down on: #14190 for you to check out when you have a moment ✌️