Loaders not called when any middleware throws an error (Framework mode)

[freshollie]

Reproduction

https://stackblitz.com/edit/github-tuw4zfdp?file=app%2Froutes%2Fsuccess.tsx,app%2Froutes%2Fnested.tsx,app%2Froutes%2Ferror.tsx,app%2Froutes.ts,app%2Froutes%2Fhome.tsx

System Info

System:
    OS: macOS 14.8.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 98.63 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.5.1 - ~/Library/Caches/fnm_multishells/38932_1759406901915/bin/node
    Yarn: 3.2.1 - ~/Library/Caches/fnm_multishells/38932_1759406901915/bin/yarn
    npm: 9.8.0 - ~/Library/Caches/fnm_multishells/38932_1759406901915/bin/npm
  Browsers:
    Chrome: 141.0.7390.55
    Safari: 26.0.1
  npmPackages:
    @react-router/dev: 7.9.2 => 7.9.2 
    @react-router/express: 7.9.2 => 7.9.2 
    @react-router/node: 7.9.2 => 7.9.2 
    @react-router/remix-routes-option-adapter: 7.9.2 => 7.9.2
    @react-router/serve: 7.9.2 => 7.9.2 
    react-router: 7.9.2 => 7.9.2 
    vite: ^6.3.5 => 6.3.5

Used Package Manager

yarn

Expected Behavior

From the docs, it seems like middleware should behave the same as loaders/actions. If a child loader/action errors, then the parent route is still rendered but the child route renders an error boundary.

I was expecting middleware to act in exactly the same way.

Actual Behavior

From debugging locally, when a child route middleware throws an error this branch is called:

react-router/packages/react-router/lib/router/router.ts

Line 3754 in d1c272a

// We never even got to the handlers, so we've got no data -

which explicitly states that we didn't make it to the "handlers", which I guess means that the loader data is not queried from the parent routes and so we render whatever we can.

If the highest parent has a loader than it will defer to the error boundary of that parent I guess because none of the loader data has been collected.

I am looking for feedback on this though, perhaps my usage in the example is wrong?

[brophdawg11]

This is correct behavior.

I was expecting middleware to act in exactly the same way.

Middleware cannot act the same because it is inherently different.

Loaders run in parallel, so when a child loader throws, as long as the parent loader suceeds, we can render the parent Component with it's corresponding loaderData, and inside the parent Outlet, we render the child ErrorBoundary.

In middleware, next() is what calls the loaders, so if a middleware throws an error before calling next() then we haven't run any loaders, and there is no loaderData available for any routes in the tree. This means we cannot render past any route that has a loader because we have no loaderData for it's Component. Therefore, we have to bubble to the highest route with a loader and start looking for an ErrorBoundary there.

[brophdawg11]

I added a note to the docs to clarify this behavior in 5344e4b

[freshollie]

I don't really understand why the matches can't just be filtered to exclude any middleware which has failed and then call the loaders for those matches? How am I supposed to use middleware as a guard if the whole app will render to the root if any error occurs in any page with a middleware (because our root has a loader?)

[freshollie]

In the docs you give examples of using middleware to fetch context used by both loader and action in a page, but if I used them that way most app UX would become considerably worse because any error from loading some data is gonna throw the whole app to the root error boundary, rather than error on that specific page.

[freshollie]

So I guess my work around is, wrap any middleware which is fetching some data for context with

try {
    const data = await getSomeData():
    context.set(dataContext, data);
} catch (e) {
    // rely on loaders which may attempt to use the context to error and go no further anyway
    await next();
    throw e;
}

Doesn't this seem a bit silly?

[brophdawg11]

I don't really understand why the matches can't just be filtered to exclude any middleware which has failed and then call the loaders for those matches?

Middleware is a prerequisite to loaders and allows loaders to be written assuming middleware has completed before they are executed. How can a loader make any of those assumptions if middlewares that throw an error are simply ignored? How do you know which errors are actually critical and which aren't?

This is a very common pattern - in both Express and Hono, if you throw an error in a middleware, it won't run the subsequent handler.

Doesn't this seem a bit silly?

Not at all - you are specifically indicating with that pattern which errors are non-critical and should not stop the chain. I'd wrap those up in the data fetching methods and type the contexts so that it's clear which data is required and won't ever be empty and which data might be empty.

async function getOptionalData(): Promise<OptionalData | null> {
  try {
    return await fetch():
  } catch (e) {
    return null;
  }
}

async function getRequiredData(): Promise<RequiredData> {
  return await fetch():
}

let optionalContext = createContext<OptionalData | null>
let requiredContext = createContext<RequiredData>

function middleware(_, next) {
  context.set(optionalContext, await getOptionalData());
  context.set(requiredContext, await getRequiredData());
  await next();  
}

[freshollie]

Appreciate the response. And I'd like to clarify btw that if this was never the intention of the design this is a fair reason to close. However:

Middleware is a prerequisite to loaders and allows loaders to be written assuming middleware has completed before they are executed.

I agree with this, but couldn't that work in a hierarchy instead? For example, if you have a child middleware, then the parent loader can still execute since it doesn't depend on the child. Since middleware are called in a chain anyway? Perhaps I'm misunderstanding the limitation.

Your example of express is simple, since there is only 1 response to deal with, my issue with this implementation is that the "initial" load of an SSR page will call multiple loaders and structure a complex response from a hierarchy of routes. Since the routes are structured within a hierarchy I don't really see understand why the loaders which need to be called at the end of the chain can't be filtered based on which of the middleware were successful?

Route hierarchy:
root (loader for app config) -> auth middleware ✅  -> page behind auth (loader) -> permission guard middleware ❌ -> page (loader should not be called)

Loaders to call:
root
page behind auth

I don't really understand why everything above the permissions guard can't be loaded?

If that's not the point in middleware, I don't really understand why middleware are structured in a hierarchy? The fact they are delcared on the routes gives enough info to determine if we should call a loader or not. If all middleware had to be declared in the root for example I'd understand the limitation you are pointing out.

[freshollie]

How can a loader make any of those assumptions if middlewares that throw an error are simply ignored? How do you know which errors are actually critical and which aren't?

On this. I don't really get the issue. No, a loader is not executed if the middleware it depends on errors. But the dependency on middleware would be based on the route hierarchy, not just a flat "if any middleware fails then no loaders will run" model.

[brophdawg11]

And I'd like to clarify btw that if this was never the intention of the design this is a fair reason to close

Yeah, this isn't the design. Middleware is a pre-process and a post-process step - not a "filtering" step to run a subset of the loaders. next is what calls continues along and loaders so without calling that it would be very misleading to still execute them. That might be what you want for a very specific use case, but if it were designed that way you'd make the following pattern impossible:

function childMiddleware(_, next) {
  if(somethingIsWrong()) {
    // I don't want to call any loaders, get me out of here
    throw new Error('Critical Error');
  }

  // All is good, call loaders
  let res = await next();
  res.setHeader('...')
  return res;
}

If you wanted an API to do what you're asking, I think the only way it would make sense is as an argument to next to say "continue along but there's an error at this level so don't go deeper".

function childMiddleware(_, next) {
  if(somethingIsWrong()) {
    // I want to call loaders to this level but no deeper
    let error = new Error('Critical Error');
    return await next(error)
  }

  // All is good, call all loaders
  let res = await next();
  res.setHeader('...')
  return res;
}

Feel free to write up a proposal according to our Open Governance Model and if enough folks are interested it might be considered

[freshollie]

// I don't want to call any loaders, get me out of here

I don't really understand the use case for not wanting to call a parent loader if the child middleware fails :/