Repository navigation
ci-fix: CI failing — Windows PowerShell browser-launch test intermittently hangs past 15s #839
Description
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
browserLaunchEnvdeliberately drops it. - Or treat the hang as a runner artifact and add a vitest
retryto this one test, knowing that would also hide a real hang.
Activity
dormouse-bot commentedon Sep 29, 2026
Triage has nothing to add to the analysis above. No other open issue or PR covers this hang. #834 is the earlier timeout bump that this report says was not enough. The failing test is inside
describe.skipIf(process.platform !== 'win32'), so this Linux triage runner can't reproduce it or try a fix. The next step is still the choice the body describes: capture the timed-out child's stderr on a Windows run, or add aretryto this one test.Recurred 2026-10-04 on docs-only PR #977 (head
a6c7f8a38082a1bff8fd2ea08598d4059118140d):runs native PowerShell startup code and exitshit ETIMEDOUT at 16.1s, and cleanup then failed with EBUSY on the temp dir (job). Failed jobs re-run.dormouse-bot commentedon Oct 7, 2026
Recurred on main 2026-10-07 at 594960a (#1011, a pgstencil dependency bump that doesn't touch the browser-launch path). This is the first failure on main since the tracker was filed; the 2026-10-04 one was on a PR. The failure matches the body:
runs native PowerShell startup code and exitshitETIMEDOUTat 15.4s, and theEBUSYrmdir on the temp dir followed. The two cmd.exe tests in the same block passed in 610ms and 60ms (job). The CI run on main just before it passed. No fix is open yet, so the decision in the body (capture stderr from the timed-out child on a Windows run, or add aretryto this one test) still needs a maintainer.dormouse-bot commentedon Oct 7, 2026
Failed again on main, about 90 minutes after the last report, at 0dfe611 (#1005, a Reopen change that doesn't touch browser launch). Same signature:
runs native PowerShell startup code and exitshitETIMEDOUTat 15.1s, then theEBUSYrmdir followed (job). That makes two failures on main in one evening. Both ran on the same runner image (windows-2025-vs202620260901.588) as the passing runs around them.One new data point bears on the hang-vs-slow question in the body. Between the two failures, main run 37553111888 passed this test in 12.6s. The other 20 main runs since 2026-10-04 took 0.6–3.8s. A 12.6s pass doesn't fit the clean split between ~2s passes and outright hangs that the body describes. It looks more like a long tail of slow
powershell.exestarts, and some of those cross the 15s budget. That doesn't settle the cause. If it is a slow tail, though, raising the test's budget or adding aretrywould hide less than the body assumed. And users of Windows PowerShell as their launch shell could occasionally hit the same 15s limit in production.No fix has been opened. The decision in the body is still open.
2026-10-07, on PR #1033 (shell-quoting fixes; doesn't change how this test's argv is quoted): same signature,
ETIMEDOUTthenEBUSY(job). It passed on rerun.dormouse-bot commentedon Oct 16, 2026
Recurred on main 2026-10-16 at 271f83e (#1139, a Hosted favicon change that doesn't touch browser launch). It's the same signature:
runs native PowerShell startup code and exitshitETIMEDOUTat 15.2s, and theEBUSYrmdir on the temp dir followed. The two cmd.exe tests in the same block passed (job).This is the first Windows failure of this test on main in the roughly 90 CI runs since the last report on 2026-10-07. The other failed main runs in that window all failed in
Build & Test, not this job. The flake is rarer than it was that evening, but it hasn't gone away. No fix is open, so the decision in the body still needs a maintainer: capture the timed-out child's stderr on a Windows run, or add aretryto this one test.dormouse-bot commentedon Oct 19, 2026
Recurred on main 2026-10-19 at 165d81b (#1182, a
fake-indexeddbbump that onlylib's tests use). Same signature:runs native PowerShell startup code and exitshitETIMEDOUTat 15.0s, then theEBUSYrmdir on the temp dir followed; both cmd.exe tests in the block passed in 63ms (job). The next CI runs on main passed. That's two main failures in three days, after none in the ~90 runs before 2026-10-16. Nothing has changed inbrowser-launch-env.tsor its test since 2026-10-02, and no fix is open, so the decision in the body still needs a maintainer.dormouse-bot commentedon Oct 20, 2026
Recurred on main 2026-10-20 at 6e58500 (#1210, a Lexical/MDXEditor Renovate rule and test that don't touch browser launch). Same signature:
runs native PowerShell startup code and exitshitETIMEDOUTat 15.1s, then theEBUSYrmdir on the temp dir followed; both cmd.exe tests in the block passed (job).That's three main failures since 2026-10-16 (10-16, 10-19, 10-20), up from none in the ~90 runs before. The only commits touching
browser-launch-env.ts, its test, orspawn.tssince 2026-10-02 are comment and type-reference edits, so the rising rate isn't coming from this code path. No fix is open; the decision in the body (capture the timed-out child's stderr on a Windows run, or add aretryto this one test) still needs a maintainer.dormouse-bot commentedon Oct 20, 2026
Recurred on main 2026-10-20 at d52fdaa (#1253, a
.gitattributesrule that keeps the bash/zsh shell-integration scripts LF; it doesn't touch browser launch or PowerShell). Same signature:runs native PowerShell startup code and exitshitETIMEDOUTat 15.3s, then theEBUSYrmdir on the temp dir followed. Both cmd.exe tests in the block passed (job). The three main runs just before it passed this test in 1.9–4.2s.This is the second failure on main today and the fourth since 2026-10-16. In the 26 main CI runs since the last report, every other red run failed in
Build & TestorWorkflow Lint, not in this job. No fix is open, so the decision in the body still needs a maintainer: capture the timed-out child's stderr on a Windows run, or add aretryto this one test.