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

[brophdawg11]

Can anyone provide a minimal repro where this happens? Does the page with the fetcher have new Link's on it that also need to be discovered? If so, it could be a race condition between the manifest loads for those and the manifest load for the fetcher call. Hard to be sure without a reproduction though...

[eugeniobet]

I'll try to add a reproduction by tomorrow, for now the following should suffice:
Create a new project with at least two routes, let's say /first and /second keeping them basically empty
Directly type the /second url onto the Browser and have a useEffect with an empty dependecy array [] navigate to /first
Watch the error happening
In our case we have an error boundary which is set to perform a document.location.reload() after a full minute so that fixes it after this period of time.
I've tried as suggested from others to delay the execution of the navigate by 1 millisecond and it seems to mitigate the problem most of the times.
The other solution suggested, the one which involves placing anywhere a tag to the route yet to be discovered seems to be the one working best.
Still, not really a fix.
Let me know if my stream of consciousness helped reproducing the problem...

[eugeniobet]

Another thought: an option to opt out of lazy route discovery altogether wouldn’t be too bad, I guess.
We use RR to handle a large application that works offline only and is served through LAN networks, where such optimizations are more of a headache. I guess we are not the only ones?

[edrpls]

I ran into this issue as well, my loader is inside a Dialog that loads on user interaction, not initial load; when called, it returns 404.

I added a hidden link in my component so that the route is loaded from the start:

<NavLink to="/my-search?query=" className="hidden">

This hack is far from ideal, but at least gets the routes working.

[lensbart]

Same issue here. The following workaround works for me as well:

setTimeout(() => fetcher.load("/some/route"), 50)

[brophdawg11]

Hey folks - I'm still not able to reproduce this - I've got a stackblitz setup with a few parallel discovery requests from eager route discovery, navigations, and fetchers, and everything seems to be working fine. Upon loading the / route, you should have fetchers load from /third and /fourth which have loaders delaying 100/200ms respectively. And also a navigation to /first which is interrupted by a navigation to /second which has a 1000ms delayed loader so you can see the fetchers complete successfully before the client side navigation away from /.

It's also worth noting that we are adding an option to disable Lazy Route discovery (#13451) so that will be available in the next release as an option too.

I'm going to close this out as not reproducible for now but please post a stackblitz reproduction if you can create one and we can reopen.

[mbrowne]

I'm encountering this error too, and I was able to create a minimal reproduction of it:
https://stackblitz.com/edit/github-k6camrjk-fhwyacas?file=app%2Froutes%2Fsecond.tsx

Click the "Second - SSR" link and you'll see the 404 error.

(This is also happening with other loaders in my app besides the get-current-user one, but in the other places it's more intermittent and harder to narrow down.)

[brophdawg11]

Thanks for the repro! Fixed in #13564 and will be available in the next release 👍

[mbrowne]

Awesome, thanks @brophdawg11 !

[github-actions]

🤖 Hello there,

We just published version 7.6.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!