fix(router): suppress abort errors in single fetch

[yoni-noma]

Description

Fixes navigation and fetcher crashes caused by inconsistent abort error shapes (AbortError, TypeError, or undefined) in single-fetch + data strategy + manifest discovery. Normalizes abort detection in one helper (isAbortError) and applies it at the entry points where browser-level aborts can race ahead of AbortController.abort() propagation.

Related: #14203

Background

AbortSignal.aborted is not always true at the moment fetches fail. The browser can terminate fetch() at the network layer (response code 0) before JavaScript's AbortController.abort() runs — most commonly during rapid navigation. In those windows, fetch throws a TypeError("Failed to fetch") while signal.aborted is still false, and the error bubbles to error boundaries as a real failure.

This PR introduces a shared isAbortError helper that detects abort situations across the variants browsers actually produce (AbortError DOMException, Error with name === "AbortError", or TypeError with a known abort message), and routes those through the existing abort suppression paths instead of error boundaries.

Changes

New shared helper

• packages/react-router/lib/router/abort.ts — isAbortError(error, signal, { allowTypeError }). Strict by signal.aborted first, then AbortError instances. TypeError message matching is opt-in (allowTypeError: true) since it can mask real network failures if applied too broadly.

Data strategy (router.ts)

• Skip aborted route results in the per-route loop so mergeLoaderData preserves the previous valid data instead of being overwritten with undefined.
• In the outer callDataStrategy catch, return empty dataResults for abort errors instead of bubbling to root.
• Reject abortPromise in callLoaderOrAction with a normalized AbortError (using signal.reason when available) so handlers can detect aborts consistently.
• Suppress abort-related errors in handleFetcherAction / handleFetcherLoader discovery error paths.
• Defensive null guards in handleFetcherAction, handleFetcherLoader, and the revalidation fetcher result merge — when callDataStrategy skips a result for abort reasons, settle the fetcher with its previous data instead of crashing on invariant(result, ...).
• Pass abort reasons through abortFetcher(key, reason) so the abort source is visible in signal.reason (helps with the observability gap the original code had).

Single fetch (single-fetch.tsx)

• fetchAndDecodeViaTurboStream normalizes a TypeError from fetch() into a proper AbortError DOMException when the signal indicates an abort, so downstream consumers see the standard shape.
• unwrapSingleFetchResultWithFallback — when SingleFetchNoResultError is thrown during a navigation race, reuse existing router.state.loaderData[routeId] if present (mirroring mergeLoaderData's preserve-existing semantics). First-time loads without prior data still throw as before.

Manifest discovery (fog-of-war.ts)

• One-time retry in fetchAndApplyManifestPatches when the initial fetch throws an abort-shaped TypeError but the signal is still active. Yields a microtask to let any pending abort() propagate, then re-checks before retrying. If the retry also fails, the error surfaces normally.
• Manifest aborts are still gated strictly on signal?.aborted (no TypeError fallback in the outer catch), preserving consistency with discoverRoutes.

Tests

• Unit tests for isAbortError covering signal state, AbortError instances, and the TypeError fallback (abort-test.ts).
• Unit test in data-strategy-test.ts asserting aborted navigations produce an AbortError result rather than undefined.
• Integration test in fetcher-test.ts exercising navigation during fetcher polling without surfacing errors.

Known limitations

• The manifest fetch retry handles the most common race but does not yet cover all observed __manifest failures in production. We're still seeing occasional manifest errors in the field — this PR reduces them substantially but does not eliminate them. Additional investigation likely needed as follow-up.
• No targeted unit tests yet for the manifest retry path or the SingleFetchNoResultError fallback; both currently rely on integration coverage from real-world usage. Happy to add focused tests if reviewers want them.

Impact

Eliminates the most common abort-related crashes (TypeError: Failed to fetch, Cannot read properties of undefined (reading 'type'), Did not find corresponding fetcher result, No result found for routeId) while leaving real navigation failures and real manifest failures visible.

[remix-cla-bot]

Hi @yoni-noma,

Welcome, and thank you for contributing to React Router!

Before we consider your pull request, we ask that you sign our Contributor License Agreement (CLA). We require this only once.

You may review the CLA and sign it by adding your name to contributors.yml.

Once the CLA is signed, the CLA Signed label will be added to the pull request.

If you have already signed the CLA and received this response in error, or if you have any questions, please contact us at hello@remix.run.

Thanks!

- The Remix team

[remix-cla-bot]

Thank you for signing the Contributor License Agreement. Let's get this merged! 🥳

[yoni-noma]

Added a short note in code: we prefer abort signal/AbortError checks and only fall back to TypeError message matching to handle browser abort race cases. The fallback is intentionally narrow (TypeError-only) to minimize false positives. Should improve behavior for Chrome/Safari/Firefox where aborted fetches sometimes surface as TypeError.

[yoni-noma]

Fix: per-route abort suppression was wiping loaderData

We discovered a bug in the per-route abort suppression logic introduced in this PR. When an aborted route result was detected in the callDataStrategy per-route loop, it was being converted to { type: ResultType.data, data: undefined }. This caused processRouteLoaderData to write undefined into loaderData, and mergeLoaderData to overwrite existing valid data with undefined.

Impact: Hooks like useRouteLoaderData('root') returned undefined after an abort race condition, causing crashes like "No requestInfo found in root loader".

Root cause: The onReject normalization (which rejects with a proper AbortError instead of undefined) made the per-route isAbortError check reachable. Before normalization, result.result was undefined and didn't match any abort pattern, so the { data: undefined } write was never reached.

Fix (commit e21f7ed): Skip aborted routes entirely (continue without writing to dataResults) instead of writing { data: undefined }. This way mergeLoaderData preserves the existing valid data for that route. The outer catch path already does this correctly by returning empty dataResults.

This is safe because:

• Routes absent from dataResults are skipped by processRouteLoaderData (line 6579: if (!(match.route.id in results)) return)
• mergeLoaderData preserves existing data for routes not present in newLoaderData (line 6732-6737)
• The abort means a new navigation is taking over, which will load fresh data
• The signal.aborted check after callDataStrategyImpl (line 3060) already discards everything if the signal caught up in time

[yoni-noma]

Fix: defensive null guards for skipped abort results in fetcher consumers

We identified two production errors caused by callDataStrategy's abort detection (isAbortError) skipping route results, while downstream fetcher consumers assume results always exist.

Sentry issues

• TypeError: Cannot read properties of undefined (reading 'type') — in handleFetcherLoader → isErrorResult(undefined) crashes when results[match.route.id] is undefined
• Error: Did not find corresponding fetcher result — in processLoaderData → invariant(result, ...) crashes when revalidation fetcher result is missing

Root cause

When a browser-level abort occurs (e.g., user navigates while fetchers are in-flight), the fetch throws a TypeError("Failed to fetch") with response code 0 while signal.aborted is still false. The isAbortError heuristic in callDataStrategy correctly identifies this as an abort and skips the result (via continue or returning empty dataResults). However, the consumers of these results don't handle the missing entry:

1. handleFetcherLoader — reads results[match.route.id] → undefined → signal.aborted is false → falls through to isErrorResult(undefined) → crash
2. handleFetcherAction — actionResult is undefined after fallback loop → isRedirectResult(undefined) / isErrorResult(undefined) → crash
3. Revalidation fetchers — callLoadersAndMaybeResolveData returns { [key]: undefined } → processLoaderData checks controller.signal.aborted → false → invariant(result, "Did not find corresponding fetcher result") → crash

Fix

Add null guards in all three consumer paths. When a result is missing (skipped by abort detection), the fetcher gracefully settles to idle with its previous data preserved — analogous to how mergeLoaderData already preserves existing navigation data for skipped routes.

No changes to abort detection logic — isAbortError, fetchAndDecodeViaTurboStream normalization, and callDataStrategy skip logic remain unchanged.

[yoni-noma]

Update: Manifest abort detection fix + fetcher discovery error guards

Problem discovered (WEB-APP-1G9)

The isAbortError check in fetchAndApplyManifestPatches was catching DOMException("AbortError") even when signal.aborted was still false (race condition). This caused an inconsistency with discoverRoutes (which checks signal.aborted), leading to:

1. fetchAndApplyManifestPatches silently returns — no routes patched
2. discoverRoutes sees signal.aborted === false, proceeds as if no abort occurred
3. Route matching fails → 404 error ("No route matches URL")

This was observed in CI (Playwright smoke tests) where rapid navigation creates tight abort timing windows.

Changes in this update

fog-of-war.ts: Reverted fetchAndApplyManifestPatches back to the original signal?.aborted check. This ensures consistency with discoverRoutes's abort detection.

router.ts: Added isAbortError guards in the discoverResult.type === "error" blocks of handleFetcherAction and handleFetcherLoader. These silently suppress abort-related discovery errors (e.g., manifest fetch aborted) in the fetcher consumers, preventing them from reaching error boundaries.

Navigation callers (the two startNavigation paths) are not modified — their existing error handling is appropriate for navigation context.

Summary of all changes in this PR

1. Abort detection (abort.ts): isAbortError helper for robust abort detection
2. Data strategy abort suppression (router.ts): Wrap callDataStrategy results to suppress abort-related errors
3. Null guards for fetcher consumers (router.ts): Defensive checks in handleFetcherLoader, handleFetcherAction, callLoadersAndMaybeResolveData
4. Manifest abort consistency (fog-of-war.ts): Keep signal?.aborted for consistency with discoverRoutes
5. Fetcher discovery error guards (router.ts): isAbortError guards in fetcher discovery error paths

[github-actions]

👋 We've moved away from Changesets to our own internal changes process. Please convert your changesets file to a change file in the proper package directory (i.e., packages/react-router/.changes/patch.fix-some-bug.md).

[Tom-DK]

Any timeline when this could be released?

[yoni-noma]

Any timeline when this could be released?

i dont think anyone reviewed it, not sure why because its pretty major issue, we had multiple crashes a week, this solved 98% of it but i think it should be reviewed carefully

[scolestock]

We think we're running into this issue as well.

[yoni-noma]

Refreshed the PR for review readiness:

• Converted the changeset file to the new .changes/ format per the bot's note above.
• Rewrote the description to reflect what the code actually does today (the original had drifted significantly across 17 commits).
• Removed unrelated prettier-style noise from the diff.
• Added unit tests for the new isAbortError helper.
• Acknowledged in "Known limitations" that the manifest fetch retry only handles the most common race — we're still seeing occasional __manifest failures and would welcome guidance on that path specifically.

@brophdawg11 — would really appreciate a review pass here when you have the bandwidth. This has been open since January and we're aware of at least 3 production users (us, @Tom-DK, @scolestock) hitting the underlying race.

The branch is behind dev and shows conflicts; happy to rebase, but the rebase needs care because #14838 and #14900 touched the same regions we patch. Would prefer directional feedback on the approach before re-deriving the patch on top of those changes.

[Alopwer]

Any updates on this issue? We have the same issue.

[davidesigner]

Same here, do you plan to merge in a near future?

[yoni-noma]

Production validation update + two related stock bugs root-caused

Since the last refresh we finished a full root-cause investigation of the crash family that remained after this PR's abort fixes, and I want to close the loop here because several people in this thread are hitting it (@Tom-DK, @scolestock, @Alopwer, @davidesigner).

TL;DR: the remaining crashes were not abort-shape issues — they are three separate stock fog-of-war bugs, all downstream of one design flaw: the "route not yet discovered" guards assume matchRoutes returns null, and any app with a root catch-all route (routes/$.tsx) never gets null. Present unchanged through 7.18.1. I've filed them separately with deterministic jest repros that run in a react-router source clone, plus validated source-level fixes:

• Catch-all route (path: "*") defeats every fog-of-war "route not yet discovered" guard — fetcher revalidation misfire + version-mismatch loop-guard silent no-op #15326 — catch-all defeats the isMidInitialLoad guard (fetcher revalidation misfires into _routes=routes/$ → SingleFetchNoResultError) and the version-mismatch loop guard silently proceeds on a stale tree instead of the document navigation its console message promises. Includes a getMatchesToLoad fix that keeps fetchers/lazy-discovery/revalidate/interruptions at 176/176.
• Aborted navigation during route discovery permanently poisons discoveredPaths — path cached as discovered, route tree never patched #15327 — an abort landing after the /__manifest JSON settles but before patch application caches the path as "discovered" while the route tree is never patched — session-sticky until hard reload. Two-line atomicity fix. (This is the clean stock repro that was requested when Lazy route discovery: discoveredPaths cache bypasses manifest version check after deploys, causing SingleFetchNoResultError #15134 was closed.)

Production numbers, for anyone evaluating whether this PR family is worth running as a patch: we vendor this PR's changes plus the three fixes above via pnpm patch on 7.13.0, tagged per-version in Sentry. Over the last 45 days: 6 No result found for routeId crashes on the older patch versions, zero since the full set deployed 5 days ago, across the same traffic. We also captured breadcrumbs of the loop-guard fix firing in the wild and recovering cleanly where stock would have crashed.

@brophdawg11 the offer from May stands: happy to rebase this PR onto dev (I know #14838/#14900 touched the same regions) — but directional feedback on the approach first would make that worthwhile. If it's easier to review piecemeal, the two issues above are self-contained starting points with runnable repros.

[scolestock]

Any new news on this one?