- Spegnimento
- 26 agosto 2026 alle ore 01:01 UTC
- Autore
- Kamo
- Impegno
- 36434f4
Risultato del compito 9: persistInbound è @Transactional, e solo il broadcast() la chiamata all'interno del loop per-membro era sicuro per l'eccezione (inghiotte i propri fallimenti) — la ricercaBySession che alimenta non era. Un transiente repository/connessione guasto ci sarebbe stato propagato fuori persistInbound e, sotto la regola di default del rollback di primavera, rotolato indietro messaggio in entrata la stessa chiamata aveva appena salvato. Avvolto l'intero ciclo nel stesso modello di prova/catch pubblicareSocialVisitor utilizza già in questa classe, e corretto il commento che overclaimed broadcast() da solo era abbastanza. Aggiunge un test di regressione che stubs trovanoBySession per lanciare e afferma persistInbound non lo propaga — il codice prefisso non aveva una tale guardia, quindi questo indica la modalità di guasto specifica la recensione contrassegnata.