pastilhasandClaude Opus 5
977d14922f
The previous commit migrated only when SQLite was completely empty, on the assumption that a non-empty file is an authoritative one. A real account disproved that within minutes of it landing. The older Gmail backfill had already written SOME keys into SQLite — last_sync_at and the uidvalidity set — and never the imap_lastuid ones. So the file was non-empty and half-migrated at the same time, all-or-nothing skipped the migration, and nine imap_lastuid keys stayed only in Postgres. A missing lastuid makes the next sync refetch that folder from UID 1: on the mailbox this was found on, 18,755 messages and 6.9 GB. Now merged per key with the file always winning a conflict. That keeps the property all-or-nothing was protecting — a restored older emails.db still overrides a newer Postgres row for every key it has, so it cannot be advanced past mail it does not contain — and adds the keys the file never had, which are exactly the ones whose absence is expensive. Verified against the live account: all 22 Postgres keys present afterwards, imap_lastuid:INBOX restored to 208407, and last_sync_at left at the file's older value, so it re-checks a fortnight rather than skipping it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>