[Bug]: Fetcher Revalidation Race Condition (Remix)

[brophdawg11]

What version of React Router are you using?

6.11.0

Steps to Reproduce

https://discord.com/channels/@me/1105622443453857842/1105623069365649458

It seems there's a race condition in Remix when the fetcher.load kicks off on initial render, and then the subsequent render-driven navigate triggers a shouldRevalidate call on the fetcher - and if the fetcher has not yet loaded the route module for the Remix route it bombs out.

The fetcher probably shouldn't attempt to revalidate at all since it's tied to a hardcoded route. With navigational loaders even on reused routes we still want to call shouldRevalidate so folks can opt-in, but with fetchers they can manually re-trigger via fetcher.load if necessary.

I do worry this fix might still have the same race condition bug if the render-driven navigation comes from useSubmit- since fetchers should attempt to revalidate after actions. But really GET-driven initial renders shouldn't trigger mutations. Worth digging a bit deeper into the Remix side of things to see if there's any avenues to look into there.

Expected Behavior

Fetcher does not try to revalidate and does not call shouldRevalidate

Actual Behavior

Fetcher is trying to revalidate before the route module loads.

[cmerrick]

@brophdawg11 I believe we're seeing this in our application, but the discord link with reproduction steps isn't accessible. Can you post the reproduction steps? Thanks!

[brophdawg11]

The reproduction is here but I'm not sure it quite reproduces on stackblitz because they serve JS files from a service worker so we don't hit the underlying race condition: https://stackblitz.com/edit/remix-run-remix-qdy2d2

[cmerrick]

Confirmed I was able to reproduce using that code once I activated Network Throttling in chrome (set to 'Slow 3G'). Error looks like this:

[n8agrin]

@brophdawg11 I hacked together a "fix" in my fork of Remix: n8agrin/remix#1

The pattern I'm noticing is that in many contexts (shouldRevalidate being just one), Remix attempts to access routeModules assuming that all possible required modules are always loaded. We're seeing that's not always the case in this issue and in the issue I'm trying to fix in this other PR: remix-run/remix#6409

My unsolicited 2c is that access to routeModules should be behind an interface that can: retrieve from local cache, load from the network or throw.

I'm trying to begin to see what that would feel like in this pr, and I don't love how the async nature of the problem demands more and more of the code be refactored to manage one small dependency.

Note that I tried the reload approach (as in remix-run/remix#6409), but that doesn't work. It creates an infinite loop within the shouldRevalide call (no surprise I suppose).

Do you have any ideas? Maybe we need to bite the bullet and do the async refactor.

[n8agrin]

@brophdawg11 just realized some of my edits span react-router and they aren’t captured here. I’ll upload the diff later. In particular I changed the createShouldRevalidate generator to async load a route module if it’s not found, which solves this issue

[brophdawg11]

This is fixed by #10623 and should be available in the next release.