Repository navigation
firstRun.renderer.test: no project within waitFor after 'Continue with a Terminal' under CI load #1435
Description
What failed
CI run 36307404914 (quality-gate, PR #1374 head 7ec048e) failed one renderer test:
src/renderer/src/features/setup/firstRun.renderer.test.tsx > first run on a Mac with no provider (#995) > explains, offers each install command, and spawns nothing until the user answers
AssertionError: expected +0 to be 1 is the final await waitFor(() => expect(projects()).toBe(1)) after clicking Continue with a Terminal: no project appeared within waitFor's default 1 s.
Why it is not #1374
#1374 changes only undoClose.ts, adds its own renderer test, and adds a plan doc. It passes locally 3/3 on the same head (Node 24). The same runner logged no space left on device and ran the renderer project for 209 s, so this is timing under load. Per the repo's rule (a waitFor timeout is a bug, not flakiness), the real question is what in the acknowledge → bootstrap → terminal-spawn chain takes more than 1 s, or waits on something the test never releases. That needs its own evidence stage; widening the timeout is not the fix.
Next step
Reproduce under load (e.g. run the renderer project with --pool contention or CPU throttling) and log each bootstrap step's timing after setupAcknowledgeNoProviders resolves.
Activity
Juliusolsson05 commentedon Sep 27, 2026
Correction (W2): I wrote that the runner was low on disk. That was wrong. The
no space left on deviceline in run 36307404914 isWorkflowBridge.test.tsINJECTING ENOSPC through its rename mock (WorkflowBridge.test.ts:34), not the runner. Other facts, rechecked:remapLiveLineageinsideuseUndoCloseAction), andfirstRun.renderer.test.tsxnever undoes a close. So fix(undo-close): a restored parent's live children follow it to its new id #1374's code is not on this test's path.It is still a real race to find (a 1 s
waitForafter 'Continue with a Terminal' that did not see a project). No rerun-as-fix.