- Expédié
- 5 août 2026 à 18:13 UTC
- Auteur
- Kamo
- Commite
- 18eca4a
Un id source dérivé de l'UUID généré par la ligne source n'est stable que si cela lignes engage. Les chemins ingest ingest VOIP écrivent à l'intérieur de la transaction de synchronisation pendant LeadCommunicationLinker s'engage dans REQUIES-NEW, donc un rollback gauche le maillon pointant un UUID qui n'a jamais existé - et le prochain balayage a frappé un nouvel UUID et relia le même appel. La contrainte unique ne pouvait pas aider, parce que la clé elle-même a changé. Les appels et les messages vocaux sont désormais à la clé de l'identité du fournisseur (instanceId:externalId), textes sur le message du fournisseur id. Ceux-ci survivent Retourner, réessayer et re-ingester, donc recommencer un balayage est vraiment idémpotent. Corrige également LeadEmailSweepState's javadoc, qui décrit toujours lastUid comme suit: Comment maintenant dit pourquoi: les UID IMAP sont réinitialisés avec UIDVALIDITY, et Graph n'a pas d'UI à GraphMessageIdService hachure le message id, donc un set de marque de haute eau à partir de la première page rejetterait presque tout après. Les deux échecs sont silencieuse, c'est précisément la raison qui appartient au dossier.