- Shipped
- September 3, 2026 at 1:04 AM UTC
- Author
- Kamo
- Commit
- 7a2aa09
MemberCreationService documented steps 4-6 as best effort, and for the emails it was not true. sendVerificationEmail is @Transactional, so it joined the member- creation transaction; when EmailService answered 500 the exception escaping it marked that transaction rollback-only. The try/catch hid the error but cannot clear the flag, so the commit threw UnexpectedRollbackException, the member that had been created in full was discarded, and the admin got a bare "Internal Server Error" with nothing in the log but a warning that read like an optional step failing. Every organization lost "Add Member" for as long as the mail path was down — which is how a one-line EmailService regression became a total outage of member creation rather than two warnings. Both sends now run from AfterCommit, past the point where a failure has anything left to poison, in MemberCreationEmailNotifier. That is a separate bean because the propagation has to reach a proxy: a commit callback still has the committed transaction bound to the thread, so plain REQUIRED would participate in a transaction Spring never commits again and the verification token would be discarded silently. One REQUIRES_NEW transaction per send, entities re-read by id because the caller's are detached by then, and each send caught by the caller — outside the transaction boundary, the only place a catch does what it looks like it does.