next.js

a8d6f7a0 - [turbopack] Fix two GC paths that leave half-torn-down dependency edges (#99902)

[turbopack] Fix two GC paths that leave half-torn-down dependency edges (#99902) ## Summary Fixes two GC bugs that each lead to a reported Turbopack panic when GC and persistent caching are both on: ``` task TaskId N (invalidate cell dependents, MustExist): task is missing in memory or persistent storage — a stale reference to an already-collected or never-created task ``` **Interrupted GC pass + eviction.** When a GC pass is interrupted, tasks would be marked deleted but tombstones would not be written. Eviction still dropped every `deleted` task anyway. The next snapshot then persisted the neighbours' halves of the torn-down edges, while the collected tasks' last snapshot stayed live on disk. A later lookup restored such a task as live and clean, with children that GC had since collected and tombstoned. Touching those children panics with `MustExist`. - Solution: eviction should not drop `deleted` tasks if the snapshot was interrupted **Resurrected task keeps stale reverse edges.** When GC collects a task `P`, it scrubbed the forward edge from each dependent `D` but deliberately left `P`'s own `cell_dependents` / `output_dependent`, since `P` was being deleted. If `P` was then resurrected, that stale entry survived. When `D` was collected later it had no forward edge to `P`, so the entry was never cleared, and the next time `P` updated the cell it panicked on the missing `D`. This only shows when `D` is inactive: a live `D` gets dirtied by `P`'s update, re-executes, and re-registers a fresh edge pair, which hides it. - Solution: GC should not assume 'deleted' tasks are always deleted! resurrection defeats it <!-- NEXT_JS_LLM -->