tests/cli/dead-browser.test.js:71 ("reports the browser is gone, then recovers on the next command", the #219 regression test) fails intermittently inside make test:
✖ reports the browser is gone, then recovers on the next command (124989.553709ms)
AssertionError: expected recovery on the next command, got:
Error: read response: read unix ->~/Library/Caches/vibium/vibium.sock: i/o timeout
daemon stop cleans up Chrome then fails with spawnSync /bin/sh ETIMEDOUT as a cascade off the wedged daemon.
Timing is the whole story:
| context |
duration |
| standalone, 2/2 runs |
~35s, passes |
inside make test |
125s, fails |
readTimeout is 60s (clicker/internal/daemon/client.go:16). The command being awaited includes a cold browser relaunch, bounded daemon-side by sessionCreateTimeout 30s (launcher.go:25) plus waitForChromedriver 10s. Those fit inside 60s when the machine is idle; under suite load the wall-clock bounds stretch past it and the client gives up first.
Raising readTimeout would hide a genuine wedge, so it is not obviously the fix. The useful question is whether the recovery path should carry a deadline derived from the launch bounds it actually waits on, rather than sharing the generic RPC deadline.
Repro is load-dependent — roughly 1 in 4 full-suite runs on a 12-core/32GB macOS VM guest. Related: #219, #231, #232, and #403.
tests/cli/dead-browser.test.js:71("reports the browser is gone, then recovers on the next command", the #219 regression test) fails intermittently insidemake test:daemon stop cleans up Chromethen fails withspawnSync /bin/sh ETIMEDOUTas a cascade off the wedged daemon.Timing is the whole story:
make testreadTimeoutis 60s (clicker/internal/daemon/client.go:16). The command being awaited includes a cold browser relaunch, bounded daemon-side bysessionCreateTimeout30s (launcher.go:25) pluswaitForChromedriver10s. Those fit inside 60s when the machine is idle; under suite load the wall-clock bounds stretch past it and the client gives up first.Raising
readTimeoutwould hide a genuine wedge, so it is not obviously the fix. The useful question is whether the recovery path should carry a deadline derived from the launch bounds it actually waits on, rather than sharing the generic RPC deadline.Repro is load-dependent — roughly 1 in 4 full-suite runs on a 12-core/32GB macOS VM guest. Related: #219, #231, #232, and #403.