- Shipped
- 27 settembre 2026 alle ore 16:25 UTC
- Author
- Kamo
- Commit
- e8d1d6a
Completa 279a389. Dopo aver spedito, la produzione ha registrato lo stesso YugabyteDB 40001 "Riavviare letto richiesto" sul roster di Exec2Exec (09-27 16:00Z, e tre volte prima quella mattina sul roster e la lista dei partecipanti): le conversazioni di Exec2Exec sono chat, ma le loro transazioni vivono in Exec2ExecService piuttosto che i controllori 279a389 coperti, quindi un conflitto ancora raggiunto il membro come un 500. Ogni operazione pubblica @Transactional Exec2ExecService ora trasporta @RetryOnDbConflict — la pagina di storia, l'invio, il gallo, i partecipanti, i conti non letti, unendo su aperto, il saluto. Il controllore li chiama attraverso il proxy e nessuno di loro cattura il conflitto, quindi ognuno è in una nuova transazione. Sicuro: gli annunci (la cornice di sessione, la ventola, la spinta) sono tutto dopo impegno, quindi un tentativo di ripiegare non ha detto niente. ChatDbConflictRetryRatchetTest ora detiene Exec2ExecService alla stessa regola.