nextjs - 💡(How to fix) Fix Pages Router Turbopack route loader times out before page registration despite successful chunks

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Code Example

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

---

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
RAW_BUFFERClick to expand / collapse

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 [email protected], where the issue still reproduces.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING