- Shipped
- August 5, 2026 at 6:13 PM UTC
- Author
- Kamo
- Commit
- 18eca4a
A source id derived from the source row's generated UUID is only stable if that row commits. The VOIP ingest paths write inside the sync transaction while LeadCommunicationLinker commits in REQUIRES_NEW, so a rollback left the link pointing at a UUID that never existed — and the next sweep minted a fresh UUID and linked the same call again. The unique constraint could not help, because the key itself changed. Calls and voicemails now key on the provider's own identity (instanceId:externalId), texts on the provider message id. Those survive rollback, retry and re-ingest, so re-running a sweep is genuinely idempotent. Also corrects LeadEmailSweepState's javadoc, which still described lastUid as comment now says why: IMAP UIDs reset with UIDVALIDITY, and Graph has no UIDs at all — GraphMessageIdService hashes the message id, so a high-water mark set from the first page would reject nearly everything after it. Both failures are silent, which is exactly why the reason belongs in the file.