bug(goal-loop): 'unrelated traffic cannot renew the screen grace' failed on main CI (2 deliveries, expected 1) #1314

Evidence

• The main push run for 54287d90 (merge of fix(dictation): cap each debug journal; bound the journal registry (#1276) #1301, dictation journal only) failed at src/main/goalLoop/GoalLoopService.test.ts:397: expected "vi.fn()" to be called 1 times, but got 2 times. Run 36156560842. The other 4461 tests passed.
• The same tree minus the merge commit passed on fix(dictation): cap each debug journal; bound the journal registry (#1276) #1301's PR run (3d1fb30 + main 3c12bb7). GoalLoopService did not change.
• Locally the test passes 15 of 15 when run alone (Node 24, -t).
• The same CI log shows many [goal-loop] persisting loop state failed: ENOENT … rename …goal-loop.json.<uuid>.tmp lines: persistence writes from earlier tests land after their temp directories were removed.

Suspected mechanism (not yet proven)

The test drives 4 × (turn_started, turn_completed) at 30 s intervals under fake timers. processState.active is latched, so each turn_completed re-enters requestContinue → holdUntilQuiet with the 45 s GOAL_LOOP_ACTIVITY_GRACE_MS. The first hold expires at about 45 s and delivers.

Whether a later turn_completed opens a second hold that also expires before the 120 s mark depends on how the async persistence in startLoop and the delivery (real fs I/O, real promises) interleaves with advanceTimersByTimeAsync. Under CI load, the ordering can let a second hold start early enough to deliver.

Next step

Instrument the test: record the delivery timestamps and the heldSince for each hold, and run the whole file under --sequence.shuffle and CPU load until it reproduces. Then decide whether a post-delivery turn_completed should open a new grace window at all; that would be a product bug, not a test bug. Never widen the timeouts.

🤖 Generated with Claude Code