You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Route module load failure during client navigation reloads the current page instead of the navigation target #15567
Result: exactly one document reload, and the page ends on /, not /todos. The retried chunk request would have succeeded, but the reload is for the location the user was leaving, so the user sees a flash and stays where they were. They have to click again.
With a permanently failing chunk the same code path reloads once and stops, so there is no loop; only the destination is lost.
When a route module fails to load during a client-side navigation, the recovery reload lands on the navigation's target location (for example, a hard navigation to the target URL instead of window.location.reload()), so a transient network failure costs one full page load rather than the navigation.
Actual Behavior
loadRouteModule (lib/dom/ssr/routeModules.ts) calls window.location.reload(). The navigation to /todos has not been committed yet, so the reload re-requests / and the navigation is dropped.
Context: a production app of ours sees this class of chunk-fetch failure regularly from mobile connections, proxies and content blockers (the asset still returns 200 on retry), so each occurrence currently costs the user a lost click.
I traced current main at a6090382ed467b5a2d46c8de1a13b331f14959f8 before attempting a patch. The hard reload is in packages/react-router/lib/dom/ssr/routeModules.ts#loadRouteModule, but that function only receives the EntryRoute and module cache. createClientRoutes closes it into the route lazy callbacks; LazyRouteFunction is zero-argument, and router.ts#loadLazyRoute calls it without the pending Location.
That means replacing window.location.reload() with route.path would not be safe: the route pattern can lose dynamic parameters, search parameters, and hash. The full destination exists earlier in router.ts#startNavigation(historyAction, location, ...), but it is not propagated to framework route-module loading.
Is there an intended recovery hook or preferred way to carry the pending navigation location to this loader? With that direction, I can prepare a focused regression test and PR rather than guessing at a new context path.
Error loading module ...*.js is a common issue with Cloudflare Pages (static hosting) after all redeployments.
I've mentioned this same location reload issue multiple times when navigating via Link after redeployment. So, I can confirm it's a big problem for pre-rendered pages.
Activity
sakura168899-debug commentedon Oct 3, 2026
I traced current main at
a6090382ed467b5a2d46c8de1a13b331f14959f8before attempting a patch. The hard reload is inpackages/react-router/lib/dom/ssr/routeModules.ts#loadRouteModule, but that function only receives theEntryRouteand module cache.createClientRoutescloses it into the routelazycallbacks;LazyRouteFunctionis zero-argument, androuter.ts#loadLazyRoutecalls it without the pendingLocation.That means replacing
window.location.reload()withroute.pathwould not be safe: the route pattern can lose dynamic parameters, search parameters, and hash. The full destination exists earlier inrouter.ts#startNavigation(historyAction, location, ...), but it is not propagated to framework route-module loading.Is there an intended recovery hook or preferred way to carry the pending navigation location to this loader? With that direction, I can prepare a focused regression test and PR rather than guessing at a new context path.
NikitaIT commentedon Oct 12, 2026
Error loading module ...*.jsis a common issue with Cloudflare Pages (static hosting) after all redeployments.I've mentioned this
same location reloadissue multiple times when navigating via Link after redeployment. So, I can confirm it's a big problem for pre-rendered pages.