WS-B follow-up: reap orphaned legacy message rows after identity migration #338

Open
opened 2026-07-31 18:52:14 +00:00 by KofTwentyTwo · 0 comments
KofTwentyTwo commented 2026-07-31 18:52:14 +00:00 (Migrated from github.com)

From the WS-B1 (#281) review. After the surrogate-id migration, legacy rows keep their old id + remote_id='imap-uid-N' + uid_validity=''; on the next re-sync the same message gets a new identity tuple -> a new surrogate id -> a second row, orphaning the legacy one (never reaped). Not data loss, not a collision (confirmed), acceptable for pre-alpha. Fix options: drop+rebuild the messages table on the identity migration (cleanest, pre-alpha data is disposable), or reap rows whose id still has the imap-uid- shape after a full re-sync, or document it. Low priority. Source: #337 review Minor #1.

From the WS-B1 (#281) review. After the surrogate-id migration, legacy rows keep their old id + remote_id='imap-uid-N' + uid_validity=''; on the next re-sync the same message gets a new identity tuple -> a new surrogate id -> a second row, orphaning the legacy one (never reaped). Not data loss, not a collision (confirmed), acceptable for pre-alpha. Fix options: drop+rebuild the messages table on the identity migration (cleanest, pre-alpha data is disposable), or reap rows whose id still has the imap-uid- shape after a full re-sync, or document it. Low priority. Source: #337 review Minor #1.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: KofTwentyTwo/nuncio#338