test: stabilize crash-isolation timeout (pre-existing flake)#95
Merged
Conversation
The crash-isolation (and process-isolation) integration tests timed out
because both guest VMs failed identically with "Cannot find module",
not because a guest crash broke its peer. VM isolation itself works: each
VM ran independently and emitted its own VM-scoped events.
Root cause: when an Execute request supplies an absolute *host* path as
the entrypoint (within the VM host cwd), prepare_javascript_shadow()
treated that host path as the guest path. It (a) materialized the
entrypoint at the wrong guest path in the shadow, and (b) never synced
the staged file into the kernel VFS. The JS runtime resolves modules
against the kernel VFS, so require("/<file>") reported "Cannot find
module" and every such process exited 1 (the healthy VM never reached
exit 0, so the test waited out its deadline).
Fix: translate the host entrypoint to its guest path (host_cwd ->
guest_cwd) before materializing, and sync the staged entrypoint into the
kernel VFS so the kernel-backed module resolver can read it.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
crash_isolation::guest_failure_in_one_vm_does_not_break_peer_vm_executiontest (and the siblingprocess_isolationtest) timed out after 10s waiting for events. This reproduces deterministically onmainand is unrelated to any security review.Root cause
It is not a crash-isolation defect — VM isolation works correctly. Both guest VMs ran fully independently and each emitted its own VM-scoped output/exit events. The test timed out because both VMs failed identically with
Error: Cannot find module '/<entry>.cjs', so the "healthy" VM exited 1 instead of 0 and the loop's completion condition (healthy.exit_code == Some(0)) was never met.The defect is in entrypoint materialization. When an
Executerequest supplies an absolute host path as the entrypoint (one that lives inside the VM's host cwd),prepare_javascript_shadow():The JavaScript runtime resolves modules against the kernel VFS (
KernelModuleFsReader), sorequire("/<entry>.cjs")could not find the module and every such process exited 1.Fix
In
prepare_javascript_shadow():host_cwd→guest_cwd) viaresolve_host_entrypoint_within_vm_host_cwdbefore keying the shadow, so the file is staged at the path the runtime actually requires.sync_shadow_entrypoint_into_kernel) so the kernel-backed module resolver can read it.The tests are unchanged — they verify the same behavior and now pass deterministically and fast (~1.1s instead of timing out at 10s). Confirmed green over repeated runs;
cargo fmt --checkandcargo clippy --workspace --all-targets -- -D warningsare clean; related sidecar suites (crash_isolation, process_isolation, vm_lifecycle, kill_cleanup, session_isolation, stdio_binary, fs_watch_and_streams, lib) pass.