- Navios
- 3 de setembro de 2026 às 01:04 UTC
- Autor
- Kamo
- Enviar
- 7a2aa09
MemberCreationService documentou as etapas 4-6 como o melhor esforço, e para os e-mails não era verdade. SendVerificationEmail is @Transactional, por isso juntou-se ao membro- transação de criação; quando EmailService respondeu 500 a exceção escapando dele assinalou apenas o retorno da transacção. A tentativa/captura escondeu o erro, mas não pode limpar a bandeira, então o commit jogou InesperadoRollbackException, o membro que tinha sido criado na íntegra foi descartado, e o administrador tem um nu "Internal Server Erro" sem nada no registro, mas um aviso que leia como um passo opcional falhando. Cada organização perdeu "Adicionar Membro" enquanto o caminho de e- mail foi para baixo — que é como uma regressão de uma linha do EmailService tornou-se um total criação de membros em vez de dois avisos. Ambos os envios agora são executados a partir do AfterCommit, depois do ponto em que uma falha tem alguma coisa deixado para envenenar, em MemberCreationEmailNotifier. Isso é um feijão separado porque a propagação tem que chegar a um proxy: um callback de commit ainda tem o transação ligada ao thread, por isso simples transaction Spring nunca mais commits e o token de verificação seria descartada silenciosamente. Uma transação REQUIRES NOVA por envio, entidades re-ler por id porque as chamadas estão separadas até lá, e cada envio é capturado pelo chamador — fora do limite da transacção, o único local onde uma captura faz o que parece Como faz.