Review: fix(router): retain pages after route data errors

Reviewed the full diff, traced the control flow through navigateClientData, navigateClientHtml, and runNavigateClient, verified Next.js parity, and ran the targeted tests. LGTM — the change is correct, well-scoped, and well-tested.

Correctness

• 5xx retain path is sound. Both navigateClientData (router.ts:1585-1592) and navigateClientHtml (router.ts:1784-1789) now throw RouteDataError on status >= 500 before reaching scheduleHardNavigationAndThrow. runNavigateClient (router.ts:2047-2053) excludes RouteDataError from the window.location.href fallback, so the page is retained while routeChangeError still fires. The two callers of runNavigateClient (push/replace at router.ts:2353, popstate at router.ts:2719) both treat "failed" as "do nothing / page stays," so the retain behavior is consistent across navigation entry points.

• Hard-nav fallbacks correctly preserved. 404 (deploy skew), missing __NEXT_DATA__, malformed JSON, invalid module path, missing loader, and non-component default exports all still route through scheduleHardNavigationAndThrow. Network errors (fetch reject) re-throw raw and hit the window.location.href fallback. Only HTTP 5xx is reclassified — matching Next.js, where a non-404 data-fetch error rejects change() and emits routeChangeError without a hard reload.

• Superseded loader suppression is correct. The new assertStillCurrent() calls in the data path (router.ts:1638) and HTML path (router.ts:1830) run inside the loader catch before scheduling recovery. For a still-current navigation they are no-ops (unchanged behavior); for a superseded one they throw NavigationCancelledError, which runNavigateClient reports as "cancelled" and skips the spurious hard nav and the second error emission.

Tests

• Core 5xx case (Pages Router failed events match Next basePath..., shims.test.ts:14101) asserts routeChangeError + win.location.href unchanged — good coverage of the retain behavior.
• New stale-loader controls for both JSON and HTML paths assert no hard nav, single error, and cancelled: true.
• New active-failure HTML control confirms a still-current loader failure still hard-navigates.
• The pre-existing popstate known failures test was correctly migrated from 500→404 (since 500 no longer hard-navigates).
• E2E spec ports the four Next.js basepath/router-events assertions (success/hash/cancelled/failed) and verifies the failed case retains the page via performance.getEntriesByType("navigation").length and a URL assertion.

All targeted tests pass; vp check clean on router.ts.

Minor (non-blocking, pre-existing)

The data and HTML loader-failure paths emit different routeChangeError messages for an active failure: the data path throws HardNavigationScheduledError("Data navigation failed: page loader threw") (router.ts:1640) while the HTML path re-throws the raw chunk error (router.ts:1831). Both still hard-navigate, so this is only a cosmetic message divergence and predates this PR — not worth blocking on, but worth noting if message parity matters later.

Review: fix(router): retain pages after route data errors

Request changes. I traced the control flow and cross-checked against the Next.js router source and the exact test this PR cites for parity. The central premise of this PR — that Next.js retains the current page (no hard reload) on an HTTP 5xx route-data failure — is incorrect. Next.js hard-navigates on 5xx data failures during client transitions, exactly as it does for 404s. This PR introduces a behavioral divergence from Next.js, and the new test assertion encodes that divergence as if it were correct.

Why this diverges from Next.js

In Next.js, fetchNextData treats any non-OK data response as a fatal asset error during a client-side transition (packages/next/src/shared/lib/router/router.ts):

const error = new Error(`Failed to load static props`)
// We should only trigger a server-side transition if this was
// caused on a client-side transition.
if (!isServerRender) {
  markAssetError(error)
}
throw error

isServerRender is this.isSsr, which is set to false at the start of every client change() (push/replace/popstate, when not query-updating; see router.ts ~L1240). So for a 5xx during a soft navigation, markAssetError(error) runs. Then in handleRouteInfoError:

if (isAssetError(err) || loadErrorFail) {
  Router.events.emit('routeChangeError', err, as, routeProps)
  // ... doing a hard reload is the proper way to deal with this.
  handleHardNavigation({ url: as, router: this })
  throw buildCancellationError()
}

→ emit routeChangeError and hard-navigate. The only status >= 500 special-case in the file is the retry loop (router.ts:464): Next.js retries 5xx a few times, then falls through to the same asset-error/hard-nav path. There is no Next.js code path that retains the previous page on a 5xx data error.

The cited parity test actually proves the opposite

The PR says it "completes the failed-route assertion in test/e2e/basepath/router-events.test.ts." That test's error-route fixture is:

// test/e2e/basepath/pages/error-route.js
export async function getServerSideProps() {
  throw new Error('KABOOM!')   // → 500 data response
}

and the _app.js that drives the event log has this comment:

// We use session storage for the event log so that it will survive
// page reloads, which happen for instance during routeChangeError

Next.js explicitly stores the log in sessionStorage because the page reloads (hard-navigates) during routeChangeError. The test only asserts the event sequence (routeChangeStart → routeChangeError "Failed to load static props"); it never asserts the page is retained. That event sequence is produced by the hard-navigation path, not by retaining the page: window.location.href = url schedules the reload as a task, so the synchronous routeChangeError listener fires first, then the document reloads.

The prior vinext code already matched Next.js

Before this PR, scheduleHardNavigationAndThrow set window.location.href = url (task-scheduled reload) and threw HardNavigationScheduledError; runNavigateClient caught it, emitted routeChangeError synchronously, and skipped a second hard nav. That produced exactly the Next.js event log and the Next.js hard navigation. The parity assertion in router-events.test.ts was already satisfiable without changing behavior.

The new unit assertion encodes the wrong behavior

tests/shims.test.ts:14150:

expect(win.location.href).toBe("http://localhost/docs/hello");  // page retained

This asserts the URL does not change on a 5xx — the opposite of Next.js, where the document hard-reloads to /docs/error-route. The test passes, but it's asserting a divergence, not parity.

Recommendation

Per AGENTS.md ("Always verify Next.js behavior first" / "If Next.js has a test, that is the authoritative answer"), the 5xx case should hard-navigate, matching 404. Concretely:

1. Drop the RouteDataError reclassification in both navigateClientData (router.ts:1585-1592) and navigateClientHtml (router.ts:1782-1790); let 5xx flow through scheduleHardNavigationAndThrow like before.
2. Remove the RouteDataError exclusion in runNavigateClient (router.ts:2047-2053).
3. Update tests/shims.test.ts:14150 to assert the hard navigation (win.location.href becomes the target), and revert the popstate test back to its 500 case (the 500→404 swap at shims.test.ts:16518 only became necessary because of this regression).

The superseded-loader suppression part of the PR (the new assertStillCurrent() calls in the loader catch blocks at router.ts:1638 and router.ts:1830, plus the stale-loader control tests) is independently correct and worth keeping — a superseded navigation should not trigger a spurious hard nav or a second error. That piece can stand on its own; it's only the 5xx retain reclassification that diverges from Next.js.

If there is a deliberate, documented reason to diverge here (it's not in the PR description), that should be called out explicitly with a Next.js issue/test reference — but the cited test and source point the other way.

Review: fix(router): ignore superseded page loader failures

Re-reviewed after the rework. I traced the control flow, diffed against the prior (incorrect) state, confirmed the divergent 5xx-retain behavior was fully reverted, and ran the targeted tests. LGTM — the central premise is now correct and matches Next.js.

The prior divergence is fully gone

The earlier RouteDataError 5xx-retain reclassification has been removed across the board:

• grep RouteDataError on router.ts → no matches.
• navigateClientData (router.ts:1580-1586): any non-OK status — including 5xx — now flows through scheduleHardNavigationAndThrow(url, "Failed to load static props"), matching Next.js's markAssetError → handleHardNavigation path.
• navigateClientHtml (router.ts:1778-1789): same — 5xx hard-navigates (the only exception is the documented allowNotFoundResponse 404 case).
• runNavigateClient (router.ts:2036-2055): no RouteDataError exclusion remains; only NavigationCancelledError short-circuits, and the HardNavigationScheduledError guard correctly avoids a double hard-nav.

This restores exact Next.js hard-navigation semantics for 5xx route-data failures.

Superseded-loader cancellation fix is independently correct

The two new assertStillCurrent() calls inside the loader catch blocks are the right, minimal fix:

• Data path (router.ts:1632): assertStillCurrent() runs before scheduleHardNavigationAndThrow, so a superseded navigation throws NavigationCancelledError instead of forcing a spurious hard nav / second error.
• HTML path (router.ts:1830-1831): same guard, then re-throws the raw chunk error for the still-current case.

For a still-current navigation both are no-ops (behavior unchanged); for a superseded one they cancel cleanly. runNavigateClient reports that as "cancelled" and suppresses the duplicate error.

Tests match the restored semantics

• Pages Router failed events match Next basePath, shape, and timing (shims.test.ts:14101): now serves HTTP 500, asserts push resolves to false (hard-nav), and asserts the exact Next.js event log (routeChangeStart → routeChangeError "Failed to load static props"). No URL-retention assertion remains.
• popstate known failures schedule a single hard navigation (shims.test.ts:16491): reverted to the 500 case and asserts a single hard navigation to /failing-page — no longer the 404 workaround that the regression had forced.
• New superseded-loader controls (JSON + HTML) assert no hard nav, a single cancelled: true error, and the winning page committed. The active-failure HTML control confirms a still-current loader failure still hard-navigates. All pass.

E2E fixture matches upstream, no over-assertion

The pages-router-basepath-dev E2E spec ports the four upstream test/e2e/basepath/router-events.test.ts assertions (success / hash / cancelled / failed). The failed-route case asserts only the event sequence — no performance.getEntriesByType("navigation") no-reload check and no URL-retention assertion — which is exactly what upstream does. The _app.tsx fixture stores the log in sessionStorage so it survives the hard reload, faithfully mirroring the upstream _app.js (whose own comment notes the log "will survive page reloads, which happen for instance during routeChangeError"). The error-route.tsx fixture throws in getServerSideProps → 500, matching upstream.

Verification run

• vp test run tests/shims.test.ts -t "superseded" → 7 passed
• vp test run tests/shims.test.ts -t "failed events match Next basePath" → 1 passed
• vp test run tests/shims.test.ts -t "popstate known failures" → 1 passed
• vp check packages/vinext/src/shims/router.ts → clean (format, lint, types)

No blocking issues. The branch now contains only the independently-valid superseded-loader cancellation fix plus the upstream basePath router-events fixture/spec, with no behavioral divergence from Next.js.

Review: fix(router): ignore superseded page loader failures

Re-reviewed the current HEAD (1b8d782). Traced the full control flow, cross-checked against the upstream Next.js basepath/router-events test, and ran the targeted suites. LGTM — the diff is exactly the independently-correct superseded-loader cancellation fix plus a faithful port of the upstream basePath router-events fixture/spec. No behavioral divergence from Next.js remains.

Diff is now minimal and correct (+7/-1 in router.ts)

The earlier 5xx-retain divergence is fully gone — grep RouteDataError on router.ts returns no matches, and the diff against the base commit contains only the two assertStillCurrent() guards:

• Data path (router.ts:1629-1635): assertStillCurrent() runs at the top of the loader catch, before scheduleHardNavigationAndThrow. A superseded navigation throws NavigationCancelledError; a still-current one falls through to the hard nav exactly as before.
• HTML path (router.ts:1827-1832): same guard, then re-throws the raw chunk error for the still-current case.

runNavigateClient (router.ts:2036-2055) has no RouteDataError/special-case exclusion — only NavigationCancelledError short-circuits to "cancelled", and the HardNavigationScheduledError guard correctly prevents a double hard-nav.

Hard-nav semantics preserved on both paths

• 5xx data responses still flow through scheduleHardNavigationAndThrow(url, "Failed to load static props") (router.ts:1580-1586), matching Next.js's markAssetError → handleHardNavigation. No page retention.
• Active (still-current) loader failures hard-navigate once on both paths: the data path sets window.location.href inside scheduleHardNavigationAndThrow and the HardNavigationScheduledError guard skips the second assignment; the HTML path re-throws raw and runNavigateClient does the single window.location.href = fullUrl. Confirmed via the new active-failure control.

Upstream parity verified

I fetched the canonical upstream test (test/e2e/basepath/router-events.test.ts). The failed-route case asserts only the event sequence (routeChangeStart → routeChangeError "Failed to load static props" null) with no URL-retention / no-reload assertion. The vinext E2E spec mirrors this exactly, and the _app.tsx fixture stores the log in sessionStorage so it survives the hard reload — faithfully matching upstream. The error-route.tsx fixture throws in getServerSideProps → 500, as upstream does. (Only cosmetic difference: vinext routes to /about where upstream uses /other-page — harmless.)

Verification run

• vp test run tests/shims.test.ts -t "superseded" → 7 passed
• vp test run tests/shims.test.ts -t "failed events match Next basePath" → 1 passed
• vp test run tests/shims.test.ts -t "popstate known failures" → 1 passed
• vp test run tests/shims.test.ts -t "concurrent navigation" → 60 passed
• vp check packages/vinext/src/shims/router.ts → clean (format, lint, types)

Minor (non-blocking, pre-existing)

The data and HTML loader-failure paths still emit different routeChangeError messages for an active failure ("Data navigation failed: page loader threw" vs. the raw chunk error). Both hard-navigate, so this is cosmetic and predates this PR. Also note the data-path active loader-failure isn't separately covered by a new unit test (only the HTML active-failure control is added); the data-path superseded case is covered. Not worth blocking on, since this PR only adds the guard before the existing, already-covered hard-nav.

No blocking issues.

Review: fix(router): ignore superseded page loader failures

Re-reviewed current HEAD (1c1b275). Traced the full control flow through navigateClientData, navigateClientHtml, navigateClient, and runNavigateClient, verified upstream Next.js parity, and ran the targeted suites. LGTM — the diff is exactly the independently-correct superseded-loader cancellation fix (+7/-1 in router.ts) plus a faithful port of the upstream basepath/router-events fixture/spec.

The fix is correct and minimal

Both page-loader catch blocks now run assertStillCurrent() before recovery:

• Data path (router.ts:1631-1635): catch → assertStillCurrent() → log → scheduleHardNavigationAndThrow. A superseded navigation throws NavigationCancelledError before the console.error and before scheduling a spurious hard nav. A still-current failure logs and hard-navigates exactly as before.
• HTML path (router.ts:1827-1832): catch → assertStillCurrent() → throw err. A superseded navigation cancels; a still-current one re-throws raw, and runNavigateClient (router.ts:2051) does the single window.location.href = fullUrl recovery.

Supersession check is race-safe

assertStillCurrent (router.ts:1936) compares the captured navId against routerRuntimeState.navigationId, which is incremented synchronously at the top of navigateClient (navId = ++routerRuntimeState.navigationId, router.ts:1933) after cancelActiveNavigation(). So a newer Router.push bumps the shared counter before any awaited loader from the prior navigation can reject — the guard reliably detects supersession at catch-time. runNavigateClient reports the resulting NavigationCancelledError as "cancelled" and suppresses the duplicate routeChangeError.

No 5xx-retain divergence remains

grep RouteDataError on router.ts → no matches. 5xx data responses (router.ts:1585) and 5xx HTML responses (router.ts:1788) still flow through scheduleHardNavigationAndThrow(url, "Failed to load static props"), matching Next.js's markAssetError → handleHardNavigation. No page retention.

Tests & fixtures match upstream

• New superseded-loader controls (JSON + HTML) assert no hard nav, a single cancelled: true error, and the winning page committed.
• The active HTML loader-failure control confirms a still-current failure hard-navigates (href → /failing-page).
• The E2E spec and _app.tsx/error-route.tsx/hello.tsx/slow-route.tsx fixtures port the four upstream test/e2e/basepath/router-events.test.ts assertions (success/hash/cancelled/failed). The failed-route case asserts only the event sequence (routeChangeStart → routeChangeError "Failed to load static props" null) — no URL-retention/no-reload assertion — exactly as upstream does, with sessionStorage mirroring the upstream _app.js that survives the hard reload.

Verification

• vp test run tests/shims.test.ts -t "superseded" → 7 passed
• vp test run tests/shims.test.ts -t "failed events match Next basePath" → 1 passed
• vp test run tests/shims.test.ts -t "popstate known failures" → 1 passed
• vp check packages/vinext/src/shims/router.ts → clean (format, lint, types)

Non-blocking notes

1. Stale PR description. The PR body still describes the reverted behavior ("keep the current page mounted when a Pages route-data request returns an HTTP 5xx", "emit routeChangeError instead of hard-navigating for route-data server failures"). The code now does the opposite (5xx hard-navigates), and the PR title correctly reflects the actual change. Worth updating the body so the merge commit / changelog isn't misleading.
2. Active-failure asymmetry (pre-existing). The data path emits routeChangeError with "Data navigation failed: page loader threw" while the HTML path re-throws the raw chunk error. Both hard-navigate; cosmetic only, predates this PR.
3. Coverage asymmetry. The data-path active loader-failure (still-current → log + hard nav) isn't separately unit-tested; only the HTML active-failure control is added. The data-path superseded case is covered. Low risk since this PR only adds the guard before an already-existing hard-nav path.

No blocking issues.

Review: fix(router): ignore superseded page loader failures

Re-reviewed current HEAD (1c1b275). Independently traced the full control flow through navigateClient, navigateClientData, navigateClientHtml, and runNavigateClient, verified Next.js parity against the cited upstream test, and ran the targeted suites. LGTM — the diff is exactly the independently-correct superseded-loader cancellation fix (+7/-1 in router.ts) plus a faithful port of the upstream basepath/router-events fixture/spec.

The fix is correct and minimal

Both page-loader catch blocks now run assertStillCurrent() before recovery:

• Data path (router.ts:1635-1638): catch → assertStillCurrent() → console.error → scheduleHardNavigationAndThrow. A superseded navigation throws NavigationCancelledError before the error log and before scheduling a spurious hard nav; a still-current failure logs and hard-navigates exactly as before (the guard is a no-op when current).
• HTML path (router.ts:1831-1836): catch → assertStillCurrent() → throw err. A superseded navigation cancels; a still-current one re-throws raw and runNavigateClient (router.ts:2056) does the single window.location.href = fullUrl recovery.

Supersession check is race-safe

assertStillCurrent (router.ts:1940) compares the captured navId against routerRuntimeState.navigationId, incremented synchronously at the top of navigateClient (++routerRuntimeState.navigationId, router.ts:1937) after cancelActiveNavigation(). A newer Router.push bumps the shared counter before any awaited loader from the prior navigation can reject, so supersession is reliably detected at catch-time. The duplicate-error suppression is also correct: cancelActiveNavigation adds the superseded controller to cancellationEventEmittedControllers and emits the routeChangeError once; navigateClient's catch (router.ts:2007) then sets err.eventEmitted = true, so runNavigateClient (router.ts:2044) skips the second emission and returns "cancelled".

Both runNavigateClient callers handle "cancelled" correctly

Push/replace (router.ts:2376) returns true; popstate (router.ts:2752) no-ops since the superseded navigation no longer wins. Consistent with Next.js cancellation semantics.

No 5xx-retain divergence remains

grep RouteDataError on router.ts / tests/ → no matches. 5xx data and HTML responses still flow through scheduleHardNavigationAndThrow(url, "Failed to load static props"), matching Next.js's markAssetError → handleHardNavigation. No page retention.

Tests & fixtures match upstream

• New superseded-loader controls (JSON + HTML) assert no hard nav, a single cancelled: true error scoped to the superseded URL, and the winning page committed.
• The active HTML loader-failure control confirms a still-current failure hard-navigates (href → /failing-page).
• The failed-events unit test (shims.test.ts:14101) serves 500, asserts push → false and the exact Next.js event log with no URL-retention assertion; the popstate test (shims.test.ts:16565) serves 500 and asserts a single hard navigation.
• The E2E spec / _app.tsx / error-route.tsx / hello.tsx / slow-route.tsx fixtures faithfully port the four upstream test/e2e/basepath/router-events.test.ts assertions; the failed case asserts only the event sequence (routeChangeStart → routeChangeError "Failed to load static props" null), with sessionStorage mirroring the upstream _app.js that survives the hard reload.

Verification

• vp test run tests/shims.test.ts -t "superseded" → 7 passed
• vp test run tests/shims.test.ts -t "failed events match Next basePath" → 1 passed
• vp test run tests/shims.test.ts -t "popstate known failures" → 1 passed
• vp check packages/vinext/src/shims/router.ts → clean (format, lint, types)

Non-blocking notes

1. Stale PR description. The PR body still describes the reverted behavior ("keep the current page mounted when a Pages route-data request returns an HTTP 5xx", "emit routeChangeError instead of hard-navigating for route-data server failures"). The code now does the opposite (5xx hard-navigates), and the title correctly reflects the actual change. Worth updating the body so the merge commit / changelog isn't misleading.
2. Coverage asymmetry (low risk). Only the HTML active-failure path has a dedicated unit control; the data-path active (still-current) loader failure isn't separately tested. The data-path superseded case is covered, and this PR only adds the no-op-when-current guard before the already-existing hard-nav, so the gap predates this change.
3. Active-failure message asymmetry (cosmetic, pre-existing). The data path emits routeChangeError with "Data navigation failed: page loader threw" while the HTML path re-throws the raw chunk error. Both hard-navigate.

No blocking issues found.

Review: fix(router): ignore superseded page loader failures

Independently traced the full control flow through navigateClient, navigateClientData, navigateClientHtml, runNavigateClient, and cancelActiveNavigation, verified Next.js parity, and ran the targeted suites on HEAD (d9f03c1). LGTM — the diff is the independently-correct superseded-loader cancellation fix (+7/-1 in router.ts) plus a faithful port of the upstream basepath/router-events fixture/spec.

The fix is correct and minimal

Both registered-loader catch blocks run assertStillCurrent() before recovery:

• Data path (router.ts:1635-1639): catch → assertStillCurrent() → console.error → scheduleHardNavigationAndThrow. A superseded navigation throws NavigationCancelledError before the error log and before scheduling a spurious hard nav; a still-current failure logs and hard-navigates exactly as before (the guard is a no-op when current).
• HTML path (router.ts:1832-1837): catch → assertStillCurrent() → throw err. A superseded navigation cancels; a still-current one re-throws raw and runNavigateClient does the single window.location.href = fullUrl recovery.

Supersession check is race-safe

assertStillCurrent (router.ts:1942) compares the captured navId against routerRuntimeState.navigationId, incremented synchronously at the top of navigateClient (++routerRuntimeState.navigationId, router.ts:1939) after cancelActiveNavigation(). A newer Router.push bumps the shared counter before any awaited loader from the prior navigation can reject, so supersession is reliably detected at catch-time. Duplicate-error suppression is also correct: cancelActiveNavigation (router.ts:1302-1305) adds the superseded controller to cancellationEventEmittedControllers and emits the routeChangeError once; navigateClient's catch (router.ts:2008-2013) sets err.eventEmitted = true, so runNavigateClient (router.ts:2046-2049) skips the second emission and returns "cancelled".

No 5xx-retain divergence remains

The prior CHANGES_REQUESTED concern is fully addressed: grep RouteDataError on packages/vinext/src/ and tests/ → no matches. 5xx data responses (router.ts:1584-1590) and 5xx HTML responses (router.ts:1783-1793) still flow through scheduleHardNavigationAndThrow(url, "Failed to load static props"), matching Next.js's markAssetError → handleHardNavigation. No page retention.

Tests & fixtures match upstream

• New superseded-loader controls (JSON + HTML) park navigation A at a deferred loader, supersede it with navigation B, then reject A — asserting no hard nav, a single cancelled: true error scoped to /page-a, and the winning page (/page-b) committed. Exactly the scenario the fix targets.
• The active HTML loader-failure control confirms a still-current failure hard-navigates (href → /failing-page).
• The E2E spec / _app.tsx / error-route.tsx / hello.tsx / slow-route.tsx fixtures faithfully port the four upstream test/e2e/basepath/router-events.test.ts assertions; the failed case asserts only the event sequence (routeChangeStart → routeChangeError "Failed to load static props" null), with sessionStorage mirroring the upstream _app.js that survives the hard reload. The second commit (read sessionStorage directly after reload, rather than via window._getEventLog()) is a sensible robustness fix — after the hard reload the fresh page may not have re-registered the helper yet.

Verification

• vp test run tests/shims.test.ts -t "superseded" → 9 passed
• vp test run tests/shims.test.ts -t "failed events match Next basePath" → 1 passed
• vp test run tests/shims.test.ts -t "popstate known failures" → 1 passed
• vp test run tests/shims.test.ts -t "concurrent navigation" → 68 passed
• vp check packages/vinext/src/shims/router.ts → clean (format, lint, types)

Non-blocking notes

1. Uncovered superseded path (pre-existing, worth a follow-up). The guard is added to the two registered-loader paths (target.loader() at router.ts:1634 and loader() at router.ts:1833). The legacy URL-import fallback pageModule = await import(pageModuleUrl) (router.ts:1849) — reached only on the HTML path when no registered loader exists — has no superseded guard. If that import rejects on a superseded navigation, it propagates as a raw error and runNavigateClient emits a routeChangeError and does window.location.href = fullUrl — the exact spurious hard-nav this PR suppresses elsewhere. This PR doesn't introduce or worsen it (it predates this change, and initial hydration registers loaders so the registered path is the common case), but it's the same class of bug and worth closing in a follow-up.
2. Stale PR description. The body still describes the reverted behavior ("keep the current page mounted when a Pages route-data request returns an HTTP 5xx", "emit routeChangeError instead of hard-navigating for route-data server failures"). The code now does the opposite (5xx hard-navigates). The title is correct, and commit subjects (which drive the auto-changeset) are correct, so the changelog is fine — but the body is misleading for reviewers and should be updated.
3. Coverage asymmetry (low risk). Only the HTML active loader-failure path has a dedicated unit control; the data-path active (still-current) loader failure isn't separately tested. The data-path superseded case is covered, and this PR only adds the no-op-when-current guard before an already-existing hard-nav.

No blocking issues found.