Repository navigation
test(session-recovery): sessionRecovery.integration fails in combined runs under load #1357
Description
Observed
src/renderer/src/workspace/hook/persistence/sessionRecovery.integration.test.ts failed in combined runs under concurrent machine load, during the reviews of #1349 (3 independent reviewers, 2026-09-27):
- with
NODE_ENV=test npx vitest run src/main/worktreeActivity src/renderer/src/workspace/hook/persistence: 63 passed, 2 failed, one a 5 s timeout and one a restored-session count mismatch; - the same failures appeared in a serial combined run (
--maxWorkers=1); - run alone, the file passed 3/3 each time;
- on an unloaded machine the combined run passes 66/66, 3/3 (author).
Not caused by #1349
#1349 changes the feed-debug persistence gate and the worktree activity index. This file uses neither and imports nothing #1349 touched: it mocks feedDebugLog and drives SessionManager plus rehydrateWorkspace.
Needs
A root cause, not a rerun. The count mismatch is not a timeout, so something ordering-dependent is at play. Candidates:
- its
vi.waitFordefault (1 s) waits on real async work; - module state shared across files in one worker (e.g.
useIpcSubscriptions' module-level maps).
Reproduce by running the combined command under CPU load; record the failing assertion and the order of events.
P3, C9.
🤖 Generated with Claude Code
Activity
Juliusolsson05 commentedon Sep 27, 2026
Needs evidence (W1): not reproducible on current main.
I ran the issue's combined command,
NODE_ENV=test npx vitest run src/main/worktreeActivity src/renderer/src/workspace/hook/persistence, onorigin/mainat 15:05 UTC:--maxWorkers=1) under heavier load (6 busy-loops, load average about 32): 76/76 passed each time.What changed since the report. The combined run now has 76 tests; the report saw 65–66. Since it was filed (03:47 UTC), #1392's feed-debug persistence fixes merged into this directory: release bookkeeping across persistence toggles, write-through during the first size check, and release on runtime-gone. "Module state shared across files in one worker" was the issue's own second candidate, so this may already be fixed. I could not prove that from a before-and-after reproduction.
Missing to act on this: the failing assertion text and the event order from a failing run on current main. Specifically:
restoredSessionsorcreateSessioncalls.I'm not adding a speculative fix without that. I'm releasing the claim.