tried to upgrade to next 16.3.0 and got this error after about a minute, server crashed

[yaelal]

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

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.

[christejab07]

I got the same error. Has it been solved?

[Umair-Malik12]

I’m experiencing the same issue as well. Upvoted the discussion to help track it.

Environment:

• Next.js: 16.3.4
• Node.js: v24.19.0
• Yarn: 4.6.0
• npm: 11.17.0

The crash occurs with the same turbo-tasks / Turbopack panic:

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

thread 'tokio-rt-worker' (12560) panicked at turbopack/crates/turbo-tasks-backend/src/backend/operation/mod.rs:292:17:
Restore of All for task TaskId 661762 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.

The application crashes while running the development server with Turbopack.

[RaJharit77]

This looks like an internal Turbopack issue rather than a project configuration problem. Providing the full RUST_BACKTRACE output should help the maintainers investigate the panic.

[gilangabdian]

there have been several recent fixes in Turbopack’s task restore/GC logic, including #98688, #98700, and #98728.

In particular, #98728 changes the restore-waiter path so a task that is no longer marked as restoring is retried instead of immediately failing with restoring failed.

Has anyone tested this issue against a recent next@canary build to confirm whether these changes resolve the panic from this discussion?

For anyone still hitting it on stable, temporarily disabling the Turbopack filesystem cache or using next dev --webpack may also be worth trying.

[QiQ-AI]

Same panic here, on Linux (WSL2) with the stable 16.3.x line:

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

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

turbo-tasks: an internal panic occurred outside the per-task panic boundary. ...
Aborting.

Environment

• Next.js 16.3.4 (Turbopack, next dev), React 19.2.8
• Node v24.18.0
• Linux 6.18 x86_64, WSL2, project on the Linux ext4 filesystem (not /mnt/c)
• Default dev filesystem cache (no experimental.turbopack* flags set); .next/dev/cache/turbopack had grown to about 9.8 GB

What was happening: a dev session that had been running for hours on a large App Router app (about 570 TS/TSX source files), with frequent edits/HMR while several headless Chromium clients requested pages at the same time. Dev-server RSS was around 5 GB. In .next/dev/trace the last events before the abort were a routine turbopack-persistence (idle timeout, about 270 MB written) followed by a turbopack-compaction (about 600 MB written, 725 MB deleted). Earlier persist/compaction cycles in the same session had no problems. No RUST_BACKTRACE capture, and no next-panic-*.log was written for this crash.

After restart: the next next dev printed ⚠ Turbopack's filesystem cache has been deleted because we previously detected an internal error in Turbopack, rebuilt cold, and has served pages normally since. So the self-invalidation worked, and it did not reproduce right away.

For anyone checking whether this is fixed: the restore-waiter fixes mentioned above (#98688, #98700, #98728, plus #99645 "stop pinning tasks during restores and always discard missing tasks") are listed in the v16.4.0 release notes. I don't see them in 16.3.5–16.3.8, so 16.3.x users may still hit this until they upgrade.