next dev: RangeError "Maximum call stack size exceeded" when the first compiled route has 8 URL segments (cacheComponents + a client component); heals after any shallower route compiles #98492

Link to the code that reproduces this issue

https://github.com/dennisat/nextjs-call-stack-size-exceeded-2026-09

To Reproduce

pnpm install
./repro.sh deep      # cold start, request /deep/a/b/c/d/e/f/g (8 segments) first
./repro.sh shallow   # cold start, request /shallow/a/b/c/d/e/f (7 segments) first

The app is a bare create-next-app with cacheComponents: true, a root layout that wraps children in a trivial
"use client" pass-through component, and two pages that return <p>ok</p>: one at 8 URL segments, one at 7.

Current vs. Expected behavior

./repro.sh deep (Node 20.16.0):

first    /deep/a/b/c/d/e/f/g   -> 500   RangeError: Maximum call stack size exceeded
second   /deep/a/b/c/d/e/f/g   -> 500
third    /shallow/a/b/c/d/e/f  -> 200
fourth   /deep/a/b/c/d/e/f/g   -> 200   ← works as soon as any shallower route has compiled

./repro.sh shallow: 200 200. The 8-segment route never fails if a shallower route compiled first, and any HMR
recompile also "fixes" it for the rest of the process. rm -rf .next brings it back on the next cold start.

Expected: 200 on every request.

Bisect (each row is one cold start requesting the 8-segment route first):

Notes:

• Dev only. next build && next start prerenders and serves the route fine.

• Page content is irrelevant (<p>ok</p>, no imports). Static folders, no dynamic segments, no nested layouts.

• Exactly 8 segments: 7 passes, 9 and deeper pass too, so this is not plain per-segment stack growth.

• The terminal only prints at ignore-listed frames; stack.txt in the repo has the 50 frames from the error page.
  The overflow lands in React Flight requireModule (loading the client reference) called from Fizz
  getComponentNameFromType, under a deep retryNode / renderNodeDestructive / renderElement / finishFunctionComponent recursion:

  RangeError: Maximum call stack size exceeded
      at requireModule            (next/dist/compiled/next-server/app-page-turbo.runtime.dev.js)
      at initializeModuleChunk
      at readChunk
      at getComponentNameFromType
      at retryNode
      at renderNodeDestructive
      at renderNode
      at renderChildrenArray
      at retryNode
      at renderElement
      ... (retryNode / renderNodeDestructive / renderElement / finishFunctionComponent repeating)
  

• Workaround: request any route with ≤ 7 segments first (or trigger any HMR recompile), or use Node 22.
  --stack-size is not applicable: Node rejects it in NODE_OPTIONS, which is how next dev passes flags to its
  render server.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.6.0 (macOS 26.6.2)
  Available memory (MB): 65536
  Available CPU cores: 10
Binaries:
  Node: 20.16.0
  npm: 10.8.1
  Yarn: 1.22.22
  pnpm: 9.9.0
Relevant Packages:
  next: 16.3.3
  eslint-config-next: N/A
  react: 19.2.8
  react-dom: 19.2.8
  typescript: 5.9.3
Next.js Config:
  output: N/A

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

cacheComponents, Turbopack, Partial Prerendering (PPR)

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

next dev (local)

Additional context

Also reproduced with [email protected]. Originally hit in a real app (Next 16.3.3, cacheComponents: true, proxy.ts rewrites) with a 27-cold-start bisect showing the same pattern; the minimal repo above removes everything
except the ingredients listed.