fix(router): suppress abort errors in single fetch

[yoni-noma]

Description

Fixes navigation/fetcher abort crashes caused by inconsistent abort error shapes (AbortError/TypeError/undefined) in single-fetch + data strategy. Normalizes aborts and ensures abortPromise rejects with AbortError so aborted handlers do not bubble to error boundaries. TypeError-message fallback only applies to fetcher aborts.

Related: #14203

Changes

• Normalize abort detection via isAbortError with a TypeError fallback only for fetchers
• Convert abort results to empty data in callDataStrategy and ignore manifest patch aborts
• Reject abortPromise with AbortError (plus dev-only debug logs)
• Add a targeted dataStrategy interruption test to assert AbortError results

Impact

Prevents abort-related TypeError/undefined errors from reaching the error boundary while keeping real navigation failures intact.

Test plan

• pnpm test packages/react-router/tests/router/data-strategy-test.ts

[changeset-bot]

🦋 Changeset detected

Latest commit: 6bfdf4e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 11 packages

Name	Type
react-router	Patch
@react-router/architect	Patch
@react-router/cloudflare	Patch
@react-router/dev	Patch
react-router-dom	Patch
@react-router/express	Patch
@react-router/node	Patch
@react-router/serve	Patch
@react-router/fs-routes	Patch
@react-router/remix-routes-option-adapter	Patch
create-react-router	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[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