Turbopack: Restore of All for task failed in another thread (panic outside per-task boundary)

[BHoopy]

Turbopack version

Unknown exact Next.js version. Paths are Windows-style (turbopack\\crates\\...). App Router (GET /en, proxy.ts).

Next.js version

Likely Next.js 16.x with Turbopack (default). next in the app is ^16.2.3.

What I did

Ran next dev. First request succeeded:

GET /en 200 in 875ms (next.js: 441ms, proxy.ts: 48ms, generate-params: 34ms, application-code: 351ms)

Then the process aborted with the panic below.

Panic

thread 'tokio-rt-worker' (18120) panicked at turbopack\crates\turbo-tasks-backend\src\backend\operation\mod.rs:292:17:
Restore of All for task TaskId 105139 failed in another thread: restoring failed
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

thread 'tokio-rt-worker' (14772) panicked at turbopack\crates\turbo-tasks-backend\src\backend\operation\mod.rs:292:17:
Restore of All for task TaskId 105139 failed in another thread: restoring failed

thread 'tokio-rt-worker' (20164) panicked at turbopack\crates\turbo-tasks-backend\src\backend\operation\mod.rs:292:17:
Restore of All for task TaskId 105139 failed in another thread: restoring failed

turbo-tasks: an internal panic occurred outside the per-task panic boundary. This is a bug in turbo-tasks/Turbopack — please report it at https://github.com/vercel/next.js/discussions and include the panic message and stack trace above.

Aborting.

Notes

This is wait_for_restore_or_panic: one worker's restore of TaskDataCategory::All for TaskId 105139 failed, and the waiting workers panic instead of invalidating the persistent cache and continuing.

Related but not the same panic: #97917 (Every task must have a task type) and #90691 (corrupted restore DB).

Workaround: delete .next (especially .next/dev/cache/turbopack) and restart next dev.

No RUST_BACKTRACE=1 capture on this run.

[Bhanuteja005]

Update with a workaround and some extra context, in case it helps triage.

Cause (as far as I can tell): the persistent dev cache under
.next/dev/cache/turbopack contains an entry that fails to deserialize.
One worker's restore of TaskDataCategory::All for the task fails, and
the other workers blocked in wait_for_restore_or_panic
(turbo-tasks-backend/src/backend/operation/mod.rs:292) panic rather than
invalidating the cache entry and recomputing. Since the panic is outside the
per-task boundary, the process aborts.

Workaround: delete .next (or just .next/dev/cache/turbopack) and restart.

Avoiding it: disabling the dev FS cache stops it entirely for me:

// next.config.ts
export default {
  experimental: {
    turbopackFileSystemCacheForDev: false,
    turbopackMemoryEviction: false,
  },
}

Environment

• Next.js: <exact version from npx next --version>
• OS: Windows ,
• Node:
• Package manager: <npm/pnpm/yarn + version>
• Project path is / is not inside OneDrive or another synced folder
• Antivirus exclusions for .next: yes / no

Suggested improvement: a failed restore of a single task seems recoverable —
could the backend invalidate that entry (or the whole persistent cache) and
recompute, instead of aborting the process? An abort with no actionable message
is a rough dev experience, and the user-facing hint doesn't currently mention
deleting .next.

I'll re-run with RUST_BACKTRACE=1 ($env:RUST_BACKTRACE=1; npm run dev in
PowerShell) and post the backtrace if I can reproduce it.

Possibly related: #97917, #90691.