Pages Router Turbopack route loader times out before page registration despite successful chunks

Link to the code that reproduces this issue

https://github.com/Stanzilla/next-turbopack-pages-router-route-loader-repro

To Reproduce

1. Clone the reproduction repository.
2. Run pnpm install.
3. Run pnpm repro.
4. Observe that the command exits non-zero after pageLoader.loadPage() rejects for several Pages Router routes.

pnpm repro runs a production Turbopack build, finds the window.__NEXT_P.push page-registration chunks, serves static assets from a separate assetPrefix origin, delays only those registration chunks, then runs a Playwright probe against window.next.router.pageLoader.loadPage().

Example failing probe summary:

{
  "pageRoute": "/track",
  "message": "Route did not complete loading: /track",
  "chunkLoaderCallsForRoute": 1,
  "nextPCallsForRoute": 0,
  "entrypointCallsForRoute": 0,
  "staticChunkResponses": 4,
  "nonOkResponses": 0,
  "failures": 0
}

A healthy control without delayed registration chunks is documented in the repository README and reports chunkLoaderCallsForRoute: 1, nextPCallsForRoute: 1, and entrypointCallsForRoute: 1.

Current vs. Expected behavior

Expected: pageLoader.loadPage('/track') should not fail once the route-list script has requested the route chunks and those static chunk requests succeed. The page should register through window.__NEXT_P.push / routeLoader.onEntrypoint, or the loader should continue/recover when the registration chunk arrives late. If a timeout is intended, the failure should distinguish a late registration chunk from a missing/failed chunk.

Actual: pageLoader.loadPage('/track') rejects with Route did not complete loading: /track even though the route chunk loader was invoked and all observed static chunk requests returned 200. In the failure case, the route never registers through window.__NEXT_P.push and routeLoader.onEntrypoint is never called. In a real production app with large Turbopack Pages Router route graphs, this causes next/link client navigation to fall back to full document navigations.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.4.0: Thu Mar 19 19:31:56 PDT 2026; root:xnu-12377.101.15~1/RELEASE_ARM64_T6030
  Available memory (MB): 36864
  Available CPU cores: 12
Binaries:
  Node: 24.15.0
  npm: 11.14.1
  Yarn: 1.22.22
  pnpm: 10.33.4
Relevant Packages:
  next: 16.3.0-canary.19 // Latest available version is detected (16.3.0-canary.19).
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: N/A
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Pages Router, Turbopack, Linking and Navigating, Runtime, Internationalization (i18n)

Which stage(s) are affected? (Select all that apply)

next build (local), next start (local), deployed production builds

Additional context

The linked reproduction is intentionally deterministic: it delays only the page-registration chunks to reproduce the same route-loader failure signature observed in production. The production failure had the same shape without artificial delay: the route-list script called __turbopack_load_page_chunks__, all target static chunks returned 200, but window.__NEXT_P.push and routeLoader.onEntrypoint never fired before loadPage() rejected.

The reproduction includes Pages Router, production Turbopack, i18n locale-prefixed URLs, assetPrefix, deploymentId, and a separate static asset origin. It is pinned to next@16.3.0-canary.19, where the issue still reproduces.

Start with the linked reproduction repository, run pnpm install and pnpm repro, then trace pageLoader.loadPage() alongside window.__NEXT_P.push and routeLoader.onEntrypoint during delayed registration chunks. Done means the delayed route registration completes successfully, or the loader reports a distinct late-registration failure, with the probe covering the failing Pages Router routes.