Skip to content

fix: hash source contents for V8 code cache - #36743

Merged
bartlomieju merged 4 commits into
mainfrom
fix/v8-code-cache-source-hash
Aug 31, 2026
Merged

bartlomieju merged 4 commits into
mainfrom
fix/v8-code-cache-source-hash

Conversation

@bartlomieju

@bartlomieju bartlomieju commented Aug 31, 2026 •

Copy link
Copy Markdown
Member

Hash full source contents when keying persistent V8 caches for CJS scripts and lazy-loaded modules, rather than relying on V8 string identity hashes. Cache callback errors now degrade to uncached compilation, and regression coverage verifies equal-length large CJS rewrites do not execute stale code.

Fixes #36413.

- Explain why `cli/rt/run.rs` hashes source bytes rather than the `&str`:
  it has to match `SharedModuleLoaderState::get_code_cache` for the same
  specifier, and the two hash differently.
- Note that `CliModuleLoader`'s two hash domains are deliberately disjoint.
- Note that hashing the pre-wrap source in the lazy ext-script path is
  sound because the wrap is a pure function of the source.
- Document on the `ModuleLoader::get_code_cache` and
  `EvalContextGetCodeCacheCb` contracts that the key must cover the full
  source, why the source arrives as UTF-16, and that `Err` degrades to an
  uncached compile.
- Factor the duplicated code-unit copy in `op_eval_context` and
  `op_compile_function` into a helper.
- Assert the eval result and that nothing is written back in the cache
  error test, and add coverage that the callback observes the full source
  contents for equal-length rewrites.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Next.js build failed with prerendering error

1 participant