Problem
src/main/db.ts runs schema migrations directly on the user's only DB. Each migration is wrapped in a transaction, so a failed ALTER TABLE rolls back — but:
- A power loss mid-migration can leave a corrupted DB
- A migration bug that passes the transaction but produces wrong data has no rollback artifact
- Users have no recovery path other than losing all notes
Fix
Before running any pending migration:
- Read current
schema_version
- If pending migrations exist, copy
lychee.sqlite3 to lychee.sqlite3.bak-v{n} in the same directory
- Keep the last N (e.g. 3) backup files, prune older
- On migration failure, log the backup path so user/support can restore
Optional: add a "Restore from backup" entry in Settings that lists available backups.
Acceptance
- After upgrading from v8 to v9, a
lychee.sqlite3.bak-v8 file exists in userData
- Forcing a migration to throw leaves the original DB usable (transaction rollback) AND leaves the backup file
Problem
src/main/db.tsruns schema migrations directly on the user's only DB. Each migration is wrapped in a transaction, so a failedALTER TABLErolls back — but:Fix
Before running any pending migration:
schema_versionlychee.sqlite3tolychee.sqlite3.bak-v{n}in the same directoryOptional: add a "Restore from backup" entry in Settings that lists available backups.
Acceptance
lychee.sqlite3.bak-v8file exists inuserData