nextjs - 💡(How to fix) Fix Turbopack `next build` hangs at 0% CPU on 16.3.0-canary.21 — fingerprint matches PR #92210 (post-fix)

Link to the code that reproduces this issue

Reproduction is in a private application repo. The bug only manifests at real-project scale (~280 routes, full Prisma + better-auth + MUI surface) — a stripped-down public reproduction may not reproduce. Full environment, configuration, and process-state captures are inline below. Happy to share a SIGUSR1 v8 stack dump, --internal-trace overview output, or a sanitized minimal reproduction on request.

To Reproduce

NODE_OPTIONS='--max-old-space-size=8192' pnpm exec next build

Default mode on Next 16.3.0-canary.21 (Turbopack-for-build).

Current vs. Expected behavior

Hang signature. next build enters the SWC compile phase ("Creating an optimized production build…" prints), then hangs indefinitely with this exact process state:

PID    STAT  %CPU  RSS         ELAPSED      COMMAND
74534  S     0.0   4342576KB   02:18:13     next-build (v16.3.0-canary.21)
74522  S     0.0   83856KB     02:18:14     node /opt/homebrew/bin/pnpm build

• Parent next-build alive, child compile workers alive, all at 0% CPU
• ~4-9 GB RSS retained
• No further writes to .next/
• Required kill -9 to clear

Hang rate. Intermittent on the same machine on the same source. Empirically ~1 in 4 cold-cache builds hang; the other 3 in 4 complete in 4-5 min. The hang appears unrelated to recent code changes (reproduces across multiple commits).

Expected. Build completes, or fails with a real error message. Silent indefinite hang shouldn't be possible.

Controlled experiments showing this is Turbopack-for-build specifically

Same project, same machine, same NODE_OPTIONS, all builds cold-cache (.next/cache .next/server .next/static wiped):

Three independent observations:

1. Webpack-for-build is reliable on Next 16 canary (4/4 successes, all timing-typical for the project size)
2. The codebase is not the cause (proven by Next 15 control — same source compiled cleanly via webpack on the last known good version)
3. Turbopack-for-build is the only configuration that hangs

Match against #92405 and PR #92210

The fingerprint (0% CPU + retained heap, large-project trigger, SWC compile phase, intermittent) matches #92405 ("Turbopack build hangs at 'Creating an optimized production build' with ~750 routes"). The Vercel team's response on #92405 attributed it to PR #92210 ("Fix DashMap read-write self-deadlock in task_cache causing hangs", merged onto canary on 2026-04-01).

PR #92210's fix should be in our 16.3.0-canary.21 build (the canary release postdates the merge). The fingerprint persists, which suggests one of:

• (a) PR #92210's fix does not cover all execution paths through get_or_create_persistent_task / get_or_create_transient_task
• (b) There's an adjacent deadlock with the same fingerprint elsewhere in the Turbopack backend (task_cache shard, or a different DashMap that wasn't audited)
• (c) The original deadlock has a regression path reintroduced after PR #92210 landed

The 4/4 webpack-mode successes rule out an SWC-level bug (SWC is shared between Turbopack and webpack, so a real SWC compile-phase deadlock would hit both engines).

Environment

OS:    macOS 26.5 (Darwin 25.5.0)
CPU:   Apple M2 (10-core)
RAM:   24 GB
Node:  25.8.2
pnpm:  10.33.0

next:                      16.3.0-canary.21
react:                     19.2.x
@prisma/client:            7.8.0
@prisma/adapter-mariadb:   7.8.0
next-intl:                 4.11.0

next.config.mjs (relevant sections)

{
  output: 'standalone',
  typescript: { ignoreBuildErrors: false },
  experimental: {
    serverActions: { bodySizeLimit: '4mb' },
    optimizePackageImports: ['@mui/material', '@mui/icons-material', '@mui/lab', /* ~12 more */],
  },
  serverExternalPackages: [
    '@aws-sdk/client-sns',
    '@aws-sdk/client-pinpoint-sms-voice-v2',
    '@aws-sdk/credential-provider-node',
    '@prisma/client',
    '@prisma/adapter-mariadb',
    'mariadb',
    '@anthropic-ai/sdk',
    'ioredis',
    'isomorphic-dompurify',
    'jsdom',
  ],
}

Project shape

• App Router only (no Pages Router)
• ~280 dynamic route handlers + page routes
• ~9,200 first-party source files (TypeScript)
• Heavy MUI surface, Prisma extension layer, better-auth plugin stack

Diagnostic captures available on request

Happy to attach any of these on a follow-up if the Turbopack team wants them:

1. SIGUSR1 v8 stack dump from a hung parent — captured via kill -SIGUSR1 <next-build pid> on Node 25+ (will catch the next reproduction)
2. --internal-trace overview output from a hang attempt (Turbopack tracing turned on)
3. --internal-trace all for the full task-level trace if overview isn't granular enough
4. ps -o pid,stat,%cpu,rss,wchan of the hung process tree to confirm what syscall/wait the workers are blocked on at hang time
5. Sanitized minimal reproduction repo with the route surface + dependency set preserved but app code stubbed — willing to put work into this if a smaller reproduction is what unblocks triage

What we've ruled out

• ❌ Our application code (Next 15 builds clean on identical source)
• ❌ Memory pressure (8 GB heap budget, 24 GB system RAM, build process at 4-9 GB RSS)
• ❌ SWC-specific bug (webpack-mode passes through SWC cleanly)
• ❌ A .next/ cache corruption (cold-cache wipes don't fix it)
• ❌ Bundler-only optimization phase (the hang is mid-compile, not in route data collection or static page generation)
• ❌ next-intl, Prisma, better-auth, MUI — webpack-mode handles all of them with the same project config

What --webpack is currently doing for us

For now we're using next build --webpack as a workaround. It's reliable but costs us the Turbopack-for-build perf story. We'd like to come back to Turbopack-for-build once this is resolved.