- Ya
- 6 Agosti 2026, 22:48 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 0fff03d
publishFor caught Exception around countByTeamMemberIdAndStatusIn and turned it into a WARN. That catch was not only around the badge: the query runs inside the caller's transaction and forces Hibernate to auto-flush the assignment rows the caller has just written, so the exception it most often sees is the caller's own write failing, not a badge that could not be read. Swallowing it bought no resilience. A failed flush has already marked the transaction rollback-only, so the commit fails regardless; all the catch changed was WHAT the caller is told — a precise DataIntegrityViolationException became an UnexpectedRollbackException whose real cause sat in a log line nobody reads. Nothing is committed at that point, so letting it out cannot strand a written attestation behind a 500. That is the whole difference from the publish hop below it, which still swallows everything: LegalAfterCommit runs after the commit, and Spring propagates an afterCommit exception to the caller, where a dead broker would turn a successful Finish into a failure the member believes.