The @vue-tui/vite suite broke main CI intermittently: full-reload.sequential's
"a genuine app exit closes the in-process dev server" failed with
"Test timed out in 5000ms" alongside "[vue-tui] failed to launch /src/main.ts"
("transport was disconnected, cannot call fetchModule").
Root cause: every *.sequential.test.ts boots a live Vite dev server, and the
fixtures have no local node_modules, so every server resolves the SAME
optimizeDeps cache dir (packages/vite/node_modules/.vite). Under the monorepo
default fileParallelism:true two dev-server files run concurrently — in SEPARATE
processes (verified: distinct pids, no shared globalThis), so the shared resource
is the FILESYSTEM, not a JS global — and their dep optimizers race on .vite/deps.
Locally this surfaces as "ENOTEMPTY: rmdir .vite/deps"; on the contended CI runner
a sibling's re-bundle invalidates a server's cache and restarts its module-runner
transport mid-import, so the exit fixture never launches and the test hits the 5s
timeout. Reproduced ~30% under CPU saturation; 0/25 after the fix.
- test.fileParallelism:false — keep exactly one dev server (and one bound port)
alive at a time, which the per-file headers already state is required. Off the
CI critical path (build->PTY dominates), so wall-clock is unaffected.
- test.testTimeout:15000 — defense-in-depth for the same failure message: the
dev-server tests poll with waitUntil (8000ms budget), ABOVE Vitest's default
5000ms test timeout, so a slow cold-optimize boot was killed by the framework
before the helper's own diagnostic could fire. Raise the ceiling above the
helper budget (mirrors overlay.sequential's 15000ms).
Test-config only; no production code changed. vp run ready green
(lint, type, 27 vite + 1290 runtime + 129 PTY, build).
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Yunfei He
345f4a5428