[Bug]: fetcher.load to "resource route" fails with 404 presumably because route has not been discovered yet

[nicksrandall]

I'm using React Router as a...

framework

Reproduction

I've linked a PR with a failing test: #13117

I have the following hook in my avatar component that fetches the current user's info:

  React.useEffect(() => {
    if (fetcher.state === "idle") {
      fetcher.load("/api/auth/me");
    }
  }, []);

This works must of the time but I have found that on some navigations I'm getting the following error in my Error Handler for my route:

data: "Error: No route matches URL \"/api/auth/me\""
error: Error: No route matches URL "/api/auth/me" at de (https://staging.brevity.io/assets/chunk-HA7DTUK3-DQvGhvXY.js:3:10042) at https://staging.brevity.io/assets/chunk-HA7DTUK3-DQvGhvXY.js:2:32011 at Array.map (<anonymous>) at wr (https://staging.brevity.io/assets/chunk-HA7DTUK3-DQvGhvXY.js:2:31771) at zn (https://staging.brevity.io/assets/chunk-HA7DTUK3-DQvGhvXY.js:2:26134) at async $e (https://staging.brevity.io/assets/chunk-HA7DTUK3-DQvGhvXY.js:2:23700) at async Object.gr [as navigate] (https://staging.brevity.io/assets/chunk-HA7DTUK3-DQvGhvXY.js:2:21930) at async https://staging.brevity.io/assets/chunk-HA7DTUK3-DQvGhvXY.js:5:6456
internal: true
status: 404
statusText: "Not Found"

This should be impossible as that route should never respond with a 404.

While I was on Remix, I could fix this issue by turning off "lazy route discovery" but not that we've migrated to React-Router there is no way to disable lazy route discovery. My thinking is that this loader is being called before the resource route has had a change to be discovered thus it's returning a 404.

One possible solution is to give me a way to opt specific routes out of lazy route discovery (ie they are always included in the original manifest).

System Info

System:
    OS: macOS 15.3.1
    CPU: (12) arm64 Apple M3 Pro
    Memory: 497.39 MB / 36.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.9.0 - ~/Library/pnpm/node
    Yarn: 1.22.22 - ~/Brevity/monorepo/node_modules/.bin/yarn
    npm: 10.9.2 - ~/Brevity/monorepo/node_modules/.bin/npm
    pnpm: 9.15.5 - ~/Library/pnpm/pnpm
    bun: 1.2.3 - ~/.bun/bin/bun
    Watchman: 2025.02.17.00 - /opt/homebrew/bin/watchman
  Browsers:
    Chrome: 133.0.6943.127
    Safari: 18.3

Used Package Manager

pnpm

Expected Behavior

I expect to be able to fetch data from a resource route without getting a 404 response.

Actual Behavior

The loader is returning a 404 error (presumably because the route hasn't been discovered yet).

[hasanayan]

We are facing the same issue. For now, as a workaround, we are adding <Link to="route/we/want/to/force/discovery"/> in the routes we get this error but we definitely need a proper fix/control for this.

[yoni-noma]

yes we are facing it as well :(

[hasanayan]

hey @brophdawg11, I am not able to create a simple project that can reproduce this. If this issue rings a bell and you can give me some pointers I can try creating a repro project.

[eugeniobet]

We are facing the same issue. For now, as a workaround, we are adding <Link to="route/we/want/to/force/discovery"/> in the routes we get this error but we definitely need a proper fix/control for this.

What do you mean you are adding it to the routes? Can you elaborate with an example? This is driving me crazy as well. Thanks

[yoni-noma]

not sure it helps anyone but In our case we found out that cloudfront cached the _manifest requests without looking at the version search param (default behavior) 😬 , even if the route was inside the old manifest it didnt had the correct version so it still caused this error.

[Varkoff]

We are facing the same issue. For now, as a workaround, we are adding <Link to="route/we/want/to/force/discovery"/> in the routes we get this error but we definitely need a proper fix/control for this.

Nice suggestion, @hasanayan ! Does it trigger the error though, or does it just inform Remix that the route exists, to prevent throwing the error ? Where exactly have you put that link ? On a public page or a private page is enough ?

Are you using the Link as-is, or are you also doing prefetch="render" to trigger a first load ?

[hasanayan]

Are you using the Link as-is, or are you also doing prefetch="render" to trigger a first load ?

We are using it as is. I think this causes eager/forced discovery of the route before the problematic useFetcher().load()call.

Where exactly have you put that link ? On a public page or a private page is enough ?

What do you mean you are adding it to the routes? Can you elaborate with an example? This is driving me crazy as well. Thanks

Based on our experience and what has been written here, we get this error after some useFetcher().load() calls (I don't know what exactly causes this, some of our useFetcher().load() calls work just fine). My workaround to work, this link should be rendered before the problematic useFetcher().load() call.

For our case we are placing it the exact routes we are doing useFetcher().load() call; Let's say you have a page at /my-route which contains a button that triggers useFetcher().load("/my-other-route") to load some data, and clicking this button causes the error being reported here. You need to place within component tree of /members

I think you can place those in the default component exported by root.tsx to make sure they are rendered on every route.

PLEASE NOTE: This is not an actual fix. It's just a workaround and hopefully react-rotuer team will introduce a proper fix for this.

Did anyone manage to reproduce this in a small project?