- Ya
- 5 Agosti 2026, 18:13 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 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.