bug(app-state): rehydrate never resolves when migrating legacy standalone prompt templates

[Juliusolsson05]

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.

[Juliusolsson05]

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 via npm run test:coverage — which also includes the system project, and therefore a different worker layout and file ordering — the same test passes.

So the shape is:

Invocation	Result
--project unit --project renderer	times out at 5s (3/3)
test:coverage (all projects)	passes

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 dynamic import('@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.