Re-synchronize a mailbox after an interruption without duplicating messages

After an interruption long enough to invalidate its checkpoint, a mailbox falls back to a full resync that never re-creates a message it already captured.

When this happens: MailboxSyncJob resumes after re-authorization and finds its stored checkpoint rejected.

Step by step

1
Reauthorizes the connection; MailboxSyncJob resumes.
The *support@* connection was offline for two days (a token refresh failure). Attempts an incremental sync using the stored Gmail historyId checkpoint. The stored historyId is more than a week old; Gmail returns 404. Falls back to a full resync: re-lists messages for the initial-sync window and checks the dedup keys — (ChannelConnectionId, provider message id) and (MailboxAddress, InternetMessageId). EasyCRM skips messages already captured before the outage; captures, groups and routes only the messages that arrived during it. Advances the checkpoint to the mailbox's current historyId.

Other paths

Microsoft graph delta token rejected

EasyCRM returns 410 Gone for an expired delta token. System applies the same full-resync fallback, deduping by conversationId instead.

Imap uidvalidity changed

The provider's UIDVALIDITY changed. Applies the same fallback, deduping by UID.

If something goes wrong

Checkpoint update never persisted

A message captured just before an earlier crash has no persisted checkpoint update. The resync re-fetches it, but the (MailboxAddress, InternetMessageId) unique index rejects the duplicate insert — treated as already captured, not an error.

Good to know

Idempotency has two layers — the generic provider-message-id key and the email-specific InternetMessageId key.
A resync never re-triggers routing, notifications or AI processing for already-captured messages.