vp run <pkg>#test hangs with run.cache: true when test uses Vitest browser mode (Playwright + Chromium)

[fengmk2]

Describe the bug

When run.cache: true is set in the workspace root config, vp run <pkg>#test hangs indefinitely with no output if the package's test script invokes Vitest in browser mode with Playwright + headless Chromium. Running vp test directly inside the package (without going through the cached task runner) completes in under one second.

Reproduction

https://github.com/forehalo/vp-test-bug

git clone https://github.com/forehalo/vp-test-bug
cd vp-test-bug
pnpm install

# Hangs indefinitely, no output, until killed
vp run website#test

# Works, passes in ~1s
cd apps/website
vp test

Setting run.cache: false in the root vite.config.ts (or cache: false on the test task entry) makes vp run website#test complete cleanly.

System info

• Platform: macOS (darwin 25.2.0, arm64)
• vite-plus: 0.1.22
• vp: v0.1.22
• pnpm: 11.1.3
• Node: >=22.12.0
• playwright: 1.60.0

Only verified on macOS so far. The existing packages/cli/snap-tests/vitest-browser-mode snap test in vite-plus is disabled on win32/darwin/linux, suggesting the issue isn't platform-specific.

[fengmk2]

The existing snap test at packages/cli/snap-tests/vitest-browser-mode in vite-plus already reproduces this problem. It was added in voidzero-dev/vite-plus#235 specifically to cover the issue, and is currently skipped on every platform (ignoredPlatforms: ["win32", "darwin", "linux"] in steps.json) because the underlying bug was never fully fixed.

Re-enabling it on darwin or linux should reproduce the hang.

[branchseer]

Root cause: fspy's receiver-side exclusive flock blocks indefinitely waiting for shared flocks held by detached descendants.

Each traced process takes a shared flock on /tmp/fspy_ipc_<uuid>.lock in its LD_PRELOAD'd ctor (crates/fspy_preload_unix/src/client/mod.rs#L48 → crates/fspy_shared/src/ipc/channel/mod.rs#L97-L99). After the immediate child exits, vt takes an exclusive flock to read the path-access messages (crates/fspy/src/unix/mod.rs#L164-L165 → crates/fspy_shared/src/ipc/channel/mod.rs#L191). Exclusive flock(2) blocks until every shared-lock holder releases — and child.wait() only tells vt about the immediate child, not detached descendants.

Vitest browser mode launches Chromium via Playwright; Chromium's main process calls setsid() and forks zygote/GPU/utility/renderer children. They inherit the lock-file FD and the shared flock travels with the open file description (lslocks shows 5+ headless_shell PIDs simultaneously holding FLOCK READ on the same lock file). When the immediate test-runner child exits, the chromium tree is still alive — vt's exclusive flock waits for it. Killing the chromium PIDs mid-hang causes vt to complete immediately, which is the proof.

It's not browser-specific. A bare task whose command detaches a backgrounded subprocess reproduces it:

# pkg/test.sh
setsid bash -c 'while true; do sleep 1; done' </dev/null >/dev/null 2>&1 &
disown

vt run mypkg#test with cache: true hangs; with cache: false it returns immediately because SpyImpl::spawn is skipped entirely.

---

Generated by Claude Code

[branchseer]

I have several ways to fix this in mind and will experiment more to decide the best one.