The v0.4 release run (https://github.com/GordonBeeming/ide/actions/runs/28936136945) failed on this App.test.tsx case with expect(element).toHaveValue("keyboard disk readme") timing out at 1070ms, while the same tree passed the full suite on the PR run and passes locally in isolation and across three consecutive full-suite runs.
The assertion relies on the default 1000ms waitFor window, and the reload-from-disk flow it drives has a few async hops (stat, read, state apply), so a loaded CI runner can push it just past the limit. Raising that assertion's waitFor timeout (or the file-level default) should be enough; the feature itself is fine.
The release was unblocked by re-running the failed job, so this is test hygiene, not a product bug.
The v0.4 release run (https://github.com/GordonBeeming/ide/actions/runs/28936136945) failed on this App.test.tsx case with
expect(element).toHaveValue("keyboard disk readme")timing out at 1070ms, while the same tree passed the full suite on the PR run and passes locally in isolation and across three consecutive full-suite runs.The assertion relies on the default 1000ms
waitForwindow, and the reload-from-disk flow it drives has a few async hops (stat, read, state apply), so a loaded CI runner can push it just past the limit. Raising that assertion'swaitFortimeout (or the file-level default) should be enough; the feature itself is fine.The release was unblocked by re-running the failed job, so this is test hygiene, not a product bug.