next.js

89f3649a - Turbopack: Panic if a top-level task attempts an eventually consistent read (#89735)

Turbopack: Panic if a top-level task attempts an eventually consistent read (#89735) We've had some really bad bugs in the past, which can be hard to root-cause due to eventually-consistent reads a the top-level, e.g. https://github.com/vercel/next.js/pull/77511 Outside of tests, there's no good justification for doing an eventually-consistent read at the top level. It may leak incomplete computations, which can contain errors that would otherwise be resolved by a strongly consistent read. The basic idea here is simple: - Store a flag in `CURRENT_TASK_STATE` indicating that we're in a top-level task. - When reading a task output or cell, check for that flag. But, there are a few complications: - `RawVc`'s read and resolution logic is wrong, and internally uses multiple eventually consistent operations after a strongly consistent read. - For this to be correct, it needs to happen as one atomic operation inside of the task backend, but it would change the backend API contract, so it's not straightforward to do that. - I added a `SUPPRESS_EVENTUAL_CONSISTENCY_TOP_LEVEL_TASK_CHECK` flag that I'm using for now. - There are a ton of places that are doing eventually consistent reads for no good reason. These aren't causing problems today, but we should fix them instead of suppressing them. Claude helped with this, but it's still a lot. - Some tests actually do need eventually-consistent reads because they're testing some internal behavior of turbo-tasks. I added an intentionally long-named `unmark_top_level_task_may_leak_eventually_consistent_state` helper for this. I manually tested `turbopack-cli` against our bundler-benchmark repository that uses it.