nextjs - 💡(How to fix) Fix next build (Turbopack) emits page.js with references to chunks that are missing on disk — non-deterministic across rebuilds

Verify canary release

• I verified that the issue exists on Next.js 16.2.4 (latest stable at the time of filing). Happy to retest on canary if the maintainers want.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin 25.4.0  (macOS 15)
Binaries:
  Node: 22.20.0
  Package manager: pnpm 9 (lockfile committed)
Relevant Packages:
  next: 16.2.4
  react: 19
  react-dom: 19
  next-intl: 4.11
  typescript: 5.x

Next 16 uses Turbopack for next build by default; no explicit --turbopack flag.

Which area(s) are affected?

Turbopack, Output (export/standalone), Module Resolution

Which stage(s) are affected?

next build (local), next start (local)

Link to the code that reproduces this issue

I don't yet have a public minimal repro — happy to put one together if maintainers want it. The triggering project is an App Router site with:

• next-intl [locale] segments (fr / en, localePrefix: "always")
• A mix of server and client section components
• next-sanity / @sanity/client used inside server components and inside generateStaticParams of two [slug] routes
• next/font (Cormorant_Garamond + Inter)
• Tailwind v4 + shadcn/ui

Stack: Next 16.2.4 + React 19 + next-intl 4.11.

To Reproduce

Repeat this loop on the project:

rm -rf .next
NODE_OPTIONS="--max-old-space-size=8192" pnpm build
pnpm start
# then curl every route in production

pnpm build always completes with no errors and prints a clean route summary. pnpm start always reports Ready in …. The first few requests succeed. Subsequent requests to different routes 500 with one of three symptoms below — and which routes 500 changes on every fresh build. Reproduced across at least 4 consecutive clean builds on the same source tree.

Symptom 1 — generated .js.map without a sibling .js

Error [ChunkLoadError]: Failed to load chunk server/chunks/ssr/messages_fr_json_[json]_cjs_0a_j2vu._.js
  Require stack:
  - .next/server/chunks/ssr/[turbopack]_runtime.js
  - .next/server/app/[locale]/contact/page.js
  ...
  [cause]: Error: Cannot find module '.../site/.next/server/chunks/ssr/messages_fr_json_[json]_cjs_0a_j2vu._.js'

On disk we see only the .map:

messages_en_json_[json]_cjs_13ct_8v._.js
messages_en_json_[json]_cjs_13ct_8v._.js.map
messages_fr_json_[json]_cjs_0a_j2vu._.js.map     # <-- .js sibling is missing

Both messages/en.json and messages/fr.json are valid JSON with identical key shapes — verified by parser and a programmatic key-set diff. The EN chunk emits; the FR chunk doesn't.

Symptom 2 — InvariantError: The client reference manifest for route "…" does not exist

⨯ Error [InvariantError]: Invariant: The client reference manifest for route "/[locale]/privacy" does not exist. This is a bug in Next.js.
    at Object.get (.next/server/chunks/ssr/[root-of-the-server]__0g2rcxp._.js:1:49487)
    at async n (.next/server/chunks/ssr/05w9_next_dist_esm_build_templates_app-page_0fi13dh.js:1:10937)

/[locale]/privacy is a small server component that imports the same shared Header / Footer every other (working) route imports. No conditional client component imports.

Symptom 3 — missing per-route runtime chunk

⨯ Error [ChunkLoadError]: Failed to load chunk server/chunks/ssr/[root-of-the-server]__0r.ks~q._.js from runtime for chunk server/app/[locale]/page.js
  [cause]: Error: Cannot find module '.../site/.next/server/chunks/ssr/[root-of-the-server]__0r.ks~q._.js'
  requireStack:
  - .next/server/chunks/ssr/[turbopack]_runtime.js
  - .next/server/app/[locale]/contact/page.js

The chunk reference is baked into the emitted page.js files, but the chunk itself is not on disk.

Non-determinism

Across 4 consecutive clean builds with no source changes:

The failures correlate with request order, not route source. Routes hit early in a server session work; routes hit later in the same session may 500 with the missing-chunk error and then return that error on every subsequent request until the server is restarted.

Webpack comparison

I tried bisecting by running next build --webpack to see whether the same routes 500 under webpack. Webpack build did not complete on this machine — both attempts errored at compile time with an unrelated network failure (build never produced an artifact):

> Build error occurred
Error: ETIMEDOUT: connection timed out, read
    at ignore-listed frames {
  errno: -60,
  code: 'ETIMEDOUT',
  syscall: 'read'
}

The project's generateStaticParams functions in two [slug] routes call next-sanity's createClient().fetch(...) over HTTPS, which works fine at runtime and works fine during the Turbopack build. The webpack build seems to handle these fetches differently (the timeouts are reproducible across two clean runs). I can dig into this separately if the maintainers consider it the same root cause; reporting it as a separate datapoint for now.

So I can't say whether webpack would also produce the missing-chunk symptom — webpack didn't get far enough to produce a build to inspect.

Current vs. expected

Current: next build claims success and prints all routes, but .next/server/chunks/ssr/ is missing one or more chunks that app/[locale]/…/page.js files reference. Server boots, then 500s when a request triggers a require on the missing chunk. Non-deterministic across rebuilds.

Expected: Either every chunk referenced by an emitted page.js is also emitted to disk, or next build fails loudly so this never reaches production.

Workarounds attempted

• rm -rf .next && pnpm build — sometimes resolves, sometimes shifts the failure to different routes.
• rm -rf node_modules/.cache && rm -rf .next && pnpm build — same.
• NODE_OPTIONS="--max-old-space-size=8192" — already set; this isn't OOM (RSS stays well under the limit and there's no OOM kill in dmesg).
• next build --webpack — see "Webpack comparison" above; couldn't produce a build to compare.

Why this matters

The intermittent nature makes this dangerous for CI/CD: a build can pass, deploy, and then 500 a subset of routes in production until someone notices. The build artifact references chunks that aren't there, but no error is raised at build time.

Happy to provide a public minimal repro on request — the symptom looks structural enough that it may reproduce on any App Router + Turbopack project with several [locale] routes and per-route async data loading, but I want to confirm before claiming that.