The Standalone Platform Check (windows-latest) job failed on main in run 36534578215. The failing test is runs native PowerShell startup code and exits. Its powershell.exe child ran into browserLaunchEnv's own 15s timeoutMs (Browser launch shell failed (…powershell.exe) … [ETIMEDOUT]).
#834 raised this block's vitest timeout to 20s, reading the earlier 5s failure as a slow cold start. This run shows that reading doesn't hold. The test's timings are bimodal. When it passes, it takes 0.75–2s (main runs 36498700094, 36500139090, 36522172034, 36527315672). When it fails, it is still running at 5s (36500112814 on main, 36515800227 on open-folder) or at 15s (this run). The shell intermittently hangs; it is not merely slow, so another timeout bump would not fix the flake. The trailing EBUSY … rmdir 'dor launch spaces & …' is a side effect: afterEach tries to delete the temp dir while the killed PowerShell still holds it as its cwd.
I haven't found the cause and didn't open a fix. The test runs only on Windows, and the evidence doesn't rule out a real intermittent hang that users with Windows PowerShell as their browser launch shell would also hit. The production budget is the same 15s. Stdin is already 'ignore' in spawnAndCapture, which rules out the usual "powershell waits on an open stdin pipe" hang. A maintainer needs to decide the next step:
- Investigate on Windows. A run that captures the timed-out child's stderr would show where it stalls; today
browserLaunchEnv deliberately drops it.
- Or treat the hang as a runner artifact and add a vitest
retry to this one test, knowing that would also hide a real hang.
The
Standalone Platform Check (windows-latest)job failed on main in run 36534578215. The failing test isruns native PowerShell startup code and exits. Itspowershell.exechild ran intobrowserLaunchEnv's own 15stimeoutMs(Browser launch shell failed (…powershell.exe) … [ETIMEDOUT]).#834 raised this block's vitest timeout to 20s, reading the earlier 5s failure as a slow cold start. This run shows that reading doesn't hold. The test's timings are bimodal. When it passes, it takes 0.75–2s (main runs 36498700094, 36500139090, 36522172034, 36527315672). When it fails, it is still running at 5s (36500112814 on main, 36515800227 on
open-folder) or at 15s (this run). The shell intermittently hangs; it is not merely slow, so another timeout bump would not fix the flake. The trailingEBUSY … rmdir 'dor launch spaces & …'is a side effect:afterEachtries to delete the temp dir while the killed PowerShell still holds it as its cwd.I haven't found the cause and didn't open a fix. The test runs only on Windows, and the evidence doesn't rule out a real intermittent hang that users with Windows PowerShell as their browser launch shell would also hit. The production budget is the same 15s. Stdin is already
'ignore'inspawnAndCapture, which rules out the usual "powershell waits on an open stdin pipe" hang. A maintainer needs to decide the next step:browserLaunchEnvdeliberately drops it.retryto this one test, knowing that would also hide a real hang.