next.js

00a671b7 - fix a snapshot encoding error that could happen under concurrent mutation and snapshotting (#92658)

fix a snapshot encoding error that could happen under concurrent mutation and snapshotting (#92658) ## What? Fixes a snapshot encoding panic introduced by #89370 in `turbopack/crates/turbo-tasks-backend/src/backend/storage.rs`. ## Why? #89370 refactored snapshot iteration and in doing so introduced two incorrect assertions in `SnapshotShardIter::next` for tasks in the `modified` list that were re-modified during snapshot iteration: 1. **`.expect("snapshot entry for modified_during_snapshot task must contain a value")`** — this panics in the `(true, false)` branch of `track_modification_internal`, where a task was modified in one category before the snapshot and then modified in a *different* category during iteration. The second modification stores a `None` entry in `snapshots` (because there was no pre-existing data to copy for that category), but the iterator unconditionally unwrapped `Some`. 2. **`debug_assert!(!inner.flags.any_modified())`** — after clearing the live `data_modified`/`meta_modified` flags and before promoting `_during_snapshot` flags, the old code asserted that no modified flags remained. This fires in the `(true, true)` branch because clearing the flags happens after the snapshot copy was taken, so the assert races with the flag state. ## How? - Unify the `direct_snapshots` fast-path and the `modified` list into a single path that handles both `(true, true)` and `(true, false)` cases gracefully: if `any_modified_during_snapshot()` is set, check the `snapshots` map — use the `Some(copy)` if present, otherwise fall back to live data (which is correct for the `None`/first-time-modified case). - Add a regression test covering the `(true, false)` branch (`modify_different_category_during_snapshot`). <!-- NEXT_JS_LLM_PR -->