Skip to content

fix: preserve operational state across schema upgrades - #2361

Merged
Astro-Han merged 2 commits into
mainfrom
fix/2357-preserve-operational-state
Aug 6, 2026
Merged

fix: preserve operational state across schema upgrades#2361
Astro-Han merged 2 commits into
mainfrom
fix/2357-preserve-operational-state

Conversation

@Astro-Han

@Astro-HanAstro-Han commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Summary

  • remove Desktop's destructive runtime.sqlite reset so existing forward migrations preserve sessions, messages, and other operational state across upgrades
  • preflight the runtime, session metadata, and registered operational schema authorities before any migration commits
  • preserve the database and fail with an actionable error when a schema is newer, unknown, or invalid
  • keep concurrent first-open behavior by configuring connection-local lock waiting before the read-only preflight
  • replace the deletion contract with upgrade-preservation and fail-closed regression coverage

Closes#2357.

Verification

  • npm run format:check
  • npm run lint
  • npm run build:workspace-deps --workspace @maka/desktop
  • npm run build:main --workspace @maka/desktop
  • node --test packages/storage/dist/__tests__/operational-state-store.test.js — 8 passed
  • node --test packages/storage/dist/__tests__/sqlite-recovery-concurrency.test.js — 8 consecutive runs passed
  • npm run test:dist --workspace=@maka/storage — 734 passed, 0 failed, 12 skipped
  • npm test — build and all affected tests passed; the command exited 1 on the existing artifact-writer-lock cleanup race (ENOTEMPTY). The same two cleanup failures reproduce on an unmodified main baseline.

Review focus

The preflight intentionally lives in the storage owner rather than Desktop. This protects CLI, headless, runtime-host, and Desktop callers and prevents an unsupported later scope from being discovered only after an earlier scope has already migrated.

The preflight sets only the connection-local busy_timeout before reading schema authorities. Persistent WAL configuration and migrations still happen only after compatibility succeeds, so a rejected database remains unchanged.

Downgrade read/write compatibility is intentionally not introduced here. A follow-up will define an explicit global minimum-reader epoch and expand/contract migration rules from a new safe baseline; this PR only stops data loss and restores the existing forward-migration path.

@Astro-Han
Astro-Han marked this pull request as ready for review August 6, 2026 19:19
@Astro-Han
Astro-Han merged commit b9873c1 into mainAug 6, 2026
@Astro-Han
Astro-Han deleted the fix/2357-preserve-operational-state branch August 6, 2026 19:20
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Incompatible operational state deletes every conversation without warning or backup

1 participant

@Astro-Han