2 Commits

Author	SHA1	Message	Date
Hendrik Liebau	f70564f742	Keep the dev validation worker alive across HMR updates (#96988) ... Cache Components dev validation reported stack frames that pointed at build output whenever a module had been updated while the dev server ran. This affected both the static shell validation and the instant-navigation validation, since both run on the same worker. The overlay showed a raw `file:` URL and the terminal named the chunk rather than the page, and because the frame never resolved to a source position there was no code frame either, so nothing indicated which line caused the error. Turbopack's server HMR evaluates an updated module as a script of its own, named `<chunk>?<module id>` and carrying its source map inline rather than on disk, so only the isolate that ran that `eval` can resolve a frame in it. The validation worker never ran it, and the map beside the chunk describes the chunk's lines, not the running module's, so nothing the worker could reach described the frame. React then wrote the frame in its form for scripts without a source map, which encodes an already-encoded URL a second time, leaving a frame no reader reverses. The worker now mirrors what the dev server does to its own module state rather than being dropped whenever that state changes. The dev server reports each applied update, the manifest cache entries it cleared, and the paths it evicted, and the worker replays them in the same order, so its module state is the dev server's module state by construction. That leaves each updated module's inline source map in the worker's own Node.js cache, which is what makes the frame resolvable there. The worker needs no coordination around a validation in flight. It runs one call at a time, in the order the calls were made, so an update is replayed before any validation requested after it, and never in the middle of one. The dev server does not hold its own updates back for a validation running in process either. Where it gives up and re-evaluates every module from disk the worker is dropped, so that case keeps the behaviour it had. Not dropping the worker helps beyond the frames. Dropping it meant the next validation had to spawn a worker thread and run `loadComponents` again before it could start, and it paid that on every edit, which delayed the insight at exactly the moment the user is waiting for it. The case in the test suite that covers this went from around 870ms to around 240ms. The simpler fix was to revive the transported errors on the main thread and print them there, where the scripts already are. It works, and it is why this PR also touches the benchmark: the fixture produced no validation errors, so nothing in the benchmark reached the error reporting at all, and the cost of moving it was invisible. With insights generated, the cost showed plainly. Printing an error costs around 218ms the first time a source map is read and about a millisecond after that, and moving it to the main thread cut the worker's p95 advantage on the heaviest route from around 15ms to between 2ms and 5ms. Mirroring the updates keeps the printing on the worker and leaves that advantage intact. The three commits are worth reading in order. The first adds the test with the broken output snapshotted, so its snapshots deliberately record what a user saw, a frame naming the chunk with no code frame beneath it. The second is the benchmark change above. The third is the fix, and its diff turns those snapshots into resolved frames, adds cases that edit the same module twice, edit a module the page imports, and validate a route that another route's update did not touch, and rewrites the suite's header comment, which described the mechanism this replaces. Verified on both bundlers, since the worker is gated on Turbopack and Webpack validates in process, along with `instant-validation-scheduling`, `instant-validation/{server-errors,parallel-slots}`, `instant-validation-causes`, `instant-validation-level-default` and `hmr-rsc-cancellation`. Run with `BENCH_DEV_VALIDATION_INSIGHTS=1`, the benchmark shows no steady-state regression: the worker column matches canary at 106ms sprite p95 against 110ms and 109ms, and keeps its margin over in-process. Two things are deliberately left out. The benchmark still cannot measure the edit case, because it never edits, so the timing above comes from a test's wall clock rather than a purpose-built measurement. And `use-cache-probe-pool` subscribes to the same invalidation and tears down the same way, which is the obvious follow-up if this holds up. One known gap remains. A worker dropped by its own failure, rather than by the dev server giving up, cannot obtain the scripts the dev server evaluated from earlier updates, so frames naming them stay unresolved until those modules change again. The validation itself is unaffected, because the worker loads the current code from disk.	2026-08-10 23:39:13 +02:00
Hendrik Liebau	59cc6420a3	Add a benchmark for dev Cache Components validation on a worker thread (#96152) ... This adds `bench/dev-validation/`, wired as `pnpm bench:dev-validation`, which measures how much dev-mode Cache Components validation contends for the dev server's event loop during rapid navigation, and how much running it on a worker thread relieves that. It toggles `experimental.devValidationWorker` (added in the previous commit) to A/B the two configurations on the same build. Until the worker implementation lands the flag is inert and the A/B shows no delta. The fixture generates one route per family (`client`, `server`, `sprite`), each nested several layout segments deep under a `(routes)` route group. Validation renders a combined payload at every URL depth, so a deeper route means more validation work per navigation, which mirrors a realistically deep app rather than a single flat segment. The runner clicks a family's `<Link>` repeatedly, since navigating to the current route re-renders and re-validates it on every click. The routes carry no `instant` config because dev validation applies to page segments by default at the warning level. The three families isolate the client prerender, the Flight re-encode plus owner-stack work, and the Flight payload size, respectively. The signal is browser-observed TTFB taken from Playwright's own network timing, because it includes the time a request waits for the event loop while validation monopolizes it. We deliberately do not use the CLI's logged request durations: the dev server starts that clock inside the request handler, after the loop has already yielded to the request, so the queue wait is invisible to it. The runner prints each configuration's absolute TTFB (p50/p95/max) side by side rather than a ratio. The time the worker frees is the validation render's CPU, which is bounded, route-dependent, and does no IO, so a ratio would overstate a win that does not scale with total request time. Because the clicks are back-to-back the numbers are a worst case — navigations that land inside the validation window — and the `max` tail is the honest headline: it is the main-thread stall the worker removes.	2026-07-25 07:21:03 +02:00