Spring Modulith: concluir um evento precisa acompanhar a transação de negócio

O Spring Modulith publicou 2.2 RC1 e as versões de manutenção 2.1.2, 2.0.9 e 1.4.14, anunciando esta última como o encerramento da série 1.x.[16] A release candidate consolida mudanças da próxima versão estável e não deve ser tratada como versão final.[16] Entre as novidades, a conclusão de uma publicação passa a participar por padrão da transação do listener.[16]

O que muda para quem desenvolve

A mudança vincula a marcação de conclusão às alterações de negócio executadas pelo listener: as operações devem ter sucesso ou falhar juntas.[16] Minha leitura é que esse vínculo deve ser um requisito verificável da aplicação, não uma suposição baseada no nome do framework.

O registro também diferencia publicações que falharam daquelas abandonadas e que não serão reenviadas.[16] A distinção importa para a operação: eu evitaria um painel que misture trabalho aguardando recuperação e trabalho encerrado por decisão explícita.

As correções descritas impedem que publicações concluídas sejam reclamadas para reenvio e ajustam o respeito à idade mínima de reenvio nos repositórios JDBC e JPA.[16] O anúncio reúne backports onde aplicáveis, mas não afirma que toda novidade da RC esteja em todas as linhas de manutenção.[16]

Como aplicar

Antes do upgrade, selecione um evento com efeito de negócio simples e defina a expectativa para cada resultado do listener. Em homologação, execute o caso bem-sucedido e confira tanto o dado alterado quanto o estado da publicação.

Depois provoque uma falha controlada antes do commit. Verifique se a alteração de negócio e a conclusão da publicação permanecem coerentes. Repita o teste com reenvio e documente quantas vezes o efeito pode ocorrer. Se houver efeitos externos à transação, trate-os como uma fronteira separada e avalie idempotência.

Adicione cenários de publicação concluída que não deve voltar à fila e publicação ainda jovem demais para reenvio. São verificações mais informativas que executar apenas uma sequência feliz após trocar a dependência.

O recurso EventResult.notToArrive() permite testar ausência de evento na nova linha.[16] Se estiver disponível na versão escolhida, use-o para explicitar efeitos que uma operação não deve produzir, sem presumir sua presença em backports.

Cuidados e limites

A 1.4.14 é apresentada como última versão 1.x, com recomendação de migração para 2.x.[16] Consulte o changelog específico da linha de destino antes de atribuir a ela uma correção mencionada no anúncio conjunto.

Minha recomendação é separar atualização de manutenção, migração de linha e avaliação da RC. São decisões com riscos diferentes. A promessa relevante não é usar a versão mais nova, mas demonstrar que falha, rollback e recuperação preservam o contrato do sistema.

Fonte

[16] Fonte: Spring Blog