- Spegnimento
- 5 agosto 2026 alle ore 18:13 UTC
- Autore
- Kamo
- Impegno
- 18eca4a
Un id sorgente derivato dal UUID generato dalla riga di origine è stabile solo se questo file si impegna. I percorsi di ingestione VOIP scrivono all'interno della transazione di sincronizzazione mentre LeadCommunicationLinker si impegna in REQUIRES NEW, quindi un rollback ha lasciato il link puntare a un UUID che non è mai esistito — e la prossima spazzata ha coniato un UUID fresco e collegato la stessa chiamata di nuovo. Il vincolo unico non poteva aiutare, perché la chiave stessa è cambiata. Chiamate e voicemail ora chiave sulla propria identità del fornitore (instanceId:externalId), testi sul messaggio del fornitore id. Quelli che sopravvivono rollback, retry e re-ingest, quindi ri-running una spazzata è veramente idempotent. Corregge anche il javadoc di LeadEmailSweepState, che ancora descritto lastUid come commento ora dice perché: IMAP UIDs reset con UIDVALIDITY, e Graph non ha UIDs a tutti — GraphMessageIdService hash il messaggio id, quindi un marchio ad alta acqua impostato da la prima pagina rifiuta quasi tutto dopo di essa. Entrambi i guasti sono silenzioso, motivo per cui il motivo appartiene al file.