Browser mode: run hangs forever when a tester page dies without closing its websocket (no run-level deadline on createTesters)

[joelfillmore]

Describe the bug

In browser mode, if a tester page's JS context dies without closing its websocket, the whole run hangs forever with no output — testTimeout, retry, and reporters all go silent until something external kills the process (locally Ctrl-C, on CI timeout-minutes).

The hang is structural — there is no run-level deadline anywhere on the per-file execution path:

• The node-side RPC to the orchestrator is created with timeout: -1 (@vitest/browser setupClient), so orchestrator.createTesters([file]) in the pool's runNextTest can wait forever. Pending calls are only rejected by the websocket close handler ("Browser connection was closed while running tests").
• In the page, the orchestrator's sendEventToIframe({ event: 'execute' }) returns a promise that resolves only when the tester posts response:execute on the BroadcastChannel — no timeout, and only an iframeerror event can reject it.
• testTimeout and retry are enforced inside the tester iframe's own JS, so once that context is gone they can never fire.

browser.connectTimeout only covers session creation; nothing covers "tester died mid-file with the socket still open."

Real triggers we hit (all funnel into the same unbounded wait):

• A mid-run dep re-optimization ("new dependencies optimized … optimized dependencies changed. reloading"): the vite full-reload destroys every tester iframe's JS context mid-file. The "Vite unexpectedly reloaded a test" warning ("Vite unexpectedly reloaded a test" warning whilst running Vitest #7333, Tests fail: "Vite unexpectedly reloaded a test. This may cause tests to fail" #8447) prints, then the run makes no further progress.
• Disk exhaustion during the run (see Browser mode: Chromium disk usage accumulates per test file, exhausting disk on long runs #9437): the vite server can no longer serve modules, the executing tester never completes, socket stays open.
• On CI (GitHub Actions, ubuntu-latest) we saw the suite go from steady per-file output to total silence mid-run, then sit for 18 minutes until timeout-minutes: 20 cancelled the job.

Reproduction

Deterministic illustration of the missing deadline (any browser-mode project, playwright provider):

1. vitest run a suite with enough files to take ~30s.
2. Mid-run, freeze the browser: pkill -STOP -f headless_shell (the websocket stays open, so the close-handler rescue never fires).
3. The run produces no further output and never times out — testTimeout cannot fire because it lives inside the frozen page.

The organic version (optimizer-reload trigger) is racy by nature: cold optimizer cache + a dep that misses the initial scan → mid-run re-optimize → full reload → hang. Observed repeatedly on a ~110-file / ~850-test storybook (@storybook/addon-vitest) suite.

Expected behavior

A tester that stops responding should fail that test file (and let the run continue or fail fast), not hang the run forever. Possible shapes: a configurable deadline around createTesters per file, or a heartbeat between orchestrator/tester and the node side that converts a dead-but-connected session into a file-level error.

Related: #9509 (load-time flakes), #10520 (hang at collection), #8447 / #7333 (unexpected reload warning), #9437 (disk accumulation — one of the triggers).

System Info

• vitest / @vitest/browser / @vitest/browser-playwright 4.1.10 (also reproduced conceptually against current dist)
• provider: playwright, chromium headless
• observed on macOS 15 (arm64), ubuntu 24 (x64 GitHub runners, docker arm64)
• node 24

Used Package Manager

pnpm

[github-actions]

Hello @joelfillmore. Please provide a minimal reproduction using a GitHub repository or StackBlitz (you can also use examples). Issues marked with needs reproduction will be closed if they have no activity within 3 days.

[guillem-aistech]

Independent corroboration from a different environment. No minimal reproduction, so treat this as a second data point rather than the repro you're asking for.

Environment

• Linux x64, 16 cores, Node v25.9.0, yarn
• playwright 1.60.0, chromium-1223, headless
• Observed on vitest@4.1.9 and vitest@5.0.0-beta.6

Symptom

On a full test run across several packages, one spec reports (0 test) — the file is picked up but registers none of its tests. A different file each time. Four distinct files so far, spanning both browser-mode and screenshot specs:

• two component browser specs (4 and 21 tests)
• two screenshot specs (18 and 9 tests)

Each was re-run individually afterwards and passed fully (4/4, 21/21, 18/18, 9/9). Only the parallel full run reproduces it.

Frequency

• 4.1.9: 3 of 3 usable full runs
• 5.0.0-beta.6: 2 of 5 full runs

Both samples are small; I would not read the difference as an improvement.

On the [birpc] rpc is closed stack

Of the three occurrences on 4.1.9, two carried it and one did not. Neither occurrence on 5.0.0-beta.6 carried it. So the stack accompanies some but not all occurrences, on both versions — consistent with your point that the pending call is incidental and only surfaces if the socket close happens to reject one. When present it read:

Caused by: Error: [birpc] rpc is closed, cannot call "resolveManualMock"
 ❯ Proxy.$close .../@vitest/browser/dist/index.js:2911
 ❯ WebSocket.emitClose .../ws/lib/websocket.js:279

What did not stop it

Serialising so that only one browser instance is alive at a time. It reduced frequency but still fired with serialisation active.

Caveat

Private repo, no minimal reproduction. I could not isolate whether the trigger is import-graph size, parallel spec count, or something else, and I did not test individual mitigations in isolation. Posting only because the "different file every run, passes alone" shape matches your description and confirms it is not specific to macOS/pnpm.

[joelfillmore]

Apologies, somehow I missed the request for a repro.

Here is a minimal reproduction: https://github.com/joelfillmore/vitest-browser-hang-repro

pnpm install && pnpm exec playwright install chromium
pnpm repro:freeze    # deterministic: freezes the tester mid-run (SIGSTOP, socket stays open)
pnpm repro:reload    # organic trigger: mid-run dep discovery -> vite full-reload

repro:freeze demonstrates the defect deterministically: a normal run (testTimeout: 10_000) is frozen mid-file with the websocket still open — no timeout ever fires and the run produces no further output until killed. The SIGSTOP is a stand-in for any silent tester death with the socket open (mid-run vite full-reload, wedged renderer, vite server unable to serve modules after disk exhaustion, #9437).

repro:reload shows the real-world trigger on every cold-cache run: a dependency hidden behind a virtual module escapes the initial dep scan, so importing it mid-run re-optimizes and full-reloads every tester ("Vite unexpectedly reloaded a test", #7333 / #8447). On a fast machine vitest recovers from the reload; under load (more files, parallel sessions, constrained CI runners) it lands while testers are mid-prepare/execute/cleanup and becomes the permanent hang — we hit this repeatedly on GitHub Actions with a ~110-file suite (steady per-file output, then total silence until timeout-minutes cancelled the job after 18 minutes).

Note on #10656 (post-4.1.10): the acknowledgement timeout bounds "tester was already dead when the message was sent", but a tester that acks execute and then dies mid-file still hangs — the response wait is unbounded and the node-side createTesters RPC uses timeout: -1.

Let me know if you'd like me to submit a PR.

Looking at this for a bit, the shape that seems to fit the existing design is extending the one-shot ack into a periodic liveness signal while work is in flight (emitted from a worker, so a legitimately sync-busy main thread does not false-positive), with the orchestrator rejecting the pending wait when the signal stops. However, not super familiar with vitest architecture so happy to defer to someone else if there is a better way to improve this.

Thanks!

[joelfillmore]

@sheremet-va - sorry I missed the request for a repro, but have added one in the comment above. Would it be possible to reopen? Thanks!

[joelfillmore]

@sheremet-va - I think it was auto-closed again because it still has the "needs reproduction" tag.

Let me know if the repro and description I linked to in my second comment is missing anything. Or whether you'd like me to submit a PR. Thanks!