Repository navigation
test: the first store.test.ts case pays the store's cold dynamic-import cost and times out under local load #686
Description
Found while working on #681. Unrelated to that change — reproduces on a clean main with the branch stashed.
Expected
useAppStore.persist.rehydrate() resolves when upgrading a version-5 settings blob that also has legacy standalone prompt templates in their own storage key.
Actual
It never resolves. The test hangs until Vitest's 5s limit:
× app store > hydrates legacy standalone prompt templates into persisted
settings during a version upgrade 5006ms
Error: Test timed out in 5000ms.
src/renderer/src/app-state/store.test.ts:40. Deterministic — three runs, 5006ms / 5017ms / 5008ms.
What narrows it
The sibling test immediately below (backfills built-in MCP defaults when hydrating a version-7 settings blob, line 65) uses the same harness, the same createStorageMock, the same dynamic import and the same await useAppStore.persist.rehydrate() — and passes. The only material difference is that the failing case seeds PROMPT_TEMPLATES_STORAGE_KEY alongside the app-store key and enters the legacy prompt-template migration path.
So the suspicion is the migration itself, not the persist harness.
Impact — genuinely unknown, and that is the concerning part
If the hang is specific to the storage mock, this is only a red test. If it reflects the real migration, a user upgrading from a v5 settings blob who has standalone prompt templates saved would have rehydrate() never resolve — which is an app that does not finish starting.
I did not investigate far enough to tell which, and did not want to guess in either direction. Worth someone establishing that before it is triaged as low priority.
Notes
- Not introduced by feat(dispatch): grid dispatch mode with per-row projects and no self-filling slots #681; verified by stashing that branch and re-running.
- Second pre-existing failure in the deterministic suite, alongside bug(testing): imageAttachment corpus test fails locally once a cited Claude session is rotated #684. Both are invisible in CI and red locally, which is the combination that trains people to ignore a red suite.
Activity
Juliusolsson05 commentedon Aug 30, 2026
Correction to the report above: this is order- or parallelism-dependent, not deterministic.
I called it deterministic on the basis of three consecutive failures, but all three were
vitest run --project unit --project renderer. Running the full deterministic suite vianpm run test:coverage— which also includes thesystemproject, and therefore a different worker layout and file ordering — the same test passes.So the shape is:
--project unit --project renderertest:coverage(all projects)That changes the likely cause and the triage. It points away from "the migration hangs" and toward something order-dependent — a leaked
vi.stubGlobal('localStorage', …), a module-registry interaction with the dynamicimport('@renderer/app-state/store'), or a persist handle surviving between files. The suite is meant to be trustworthy under arbitrary file ordering, so that is still a real defect, but it is a test-isolation one rather than a product hang.I should not have called it deterministic off a single invocation shape. The "app that does not finish starting" concern in the original report is correspondingly much weaker — no evidence now points at the real migration.
[-]bug(app-state): rehydrate never resolves when migrating legacy standalone prompt templates[/-][+]test: the first store.test.ts case pays the store's cold dynamic-import cost and times out under local load[/+]Juliusolsson05 commentedon Sep 27, 2026
Retitled (triage 2026-09-27). This is not a real rehydrate hang. It's a cold dynamic import after
vi.resetModules()that takes longer than 5 s under local load, and it passes alone and in CI. Low priority, with no user impact, but it keeps the local suite red.