What?

Add a debug_assert! in StorageWriteGuard::track_modification to enforce that transient TaskIds are never inserted into the persistence-modified set.

Why?

Concurrent server component HMR updates triggered a runtime panic in Turbopack:

internal error: entered unreachable code: transient task_ids should never be enqueued to be persisted

This unreachable! lives in snapshot_and_persist (backend/mod.rs:1254), which is called during the persist cycle. It fires when a transient TaskId is found in Storage::modified — the set that tracks tasks whose state needs to be written to disk.

Transient task IDs (high bit set) are never serialized. The invariant was enforced only at the caller layer:

• TaskGuardImpl::track_modification (operation/mod.rs:1029) guards with if !self.task_id.is_transient()
• TaskGuardImpl::invalidate_serialization (operation/mod.rs:970) guards with if !self.task_id.is_transient()

But StorageWriteGuard::track_modification — the public method on the storage struct itself — had no such guard. Under concurrent HMR invalidations, a transient task ID could reach this method via a code path that bypasses the caller-level checks, inserting the ID into Storage::modified and causing the panic downstream during the next persist cycle.

The flaky test is test/development/app-dir/hmr-iframe/hmr-iframe.test.ts — it triggers two simultaneous server component file changes (one in an iframe, one in the parent), which races the persist cycle against concurrent invalidations.

How?

Add a debug_assert! in StorageWriteGuard::track_modification (the sole public entry point into the storage mutation path) that matches the invariant already checked at the caller layer:

debug_assert!(
    !self.inner.key().is_transient(),
    "transient task_ids should never be enqueued to be persisted"
);

This enforces the invariant at the storage boundary in debug builds, surfacing the violation at the point of insertion rather than much later during the persist cycle. The message deliberately matches the existing unreachable! downstream so both failure modes are easy to correlate.

Verification:

• cargo test -p turbo-tasks-backend — all unit tests pass
• pnpm build-all — build succeeds
• NEXT_SKIP_ISOLATE=1 NEXT_TEST_MODE=dev pnpm testheadless test/development/app-dir/hmr-iframe/hmr-iframe.test.ts — 3/3 consecutive passes (was flaky before)