Reagenda entrega de webhook quando a falha é temporária

[Hirley]

Fecha #76.

WebhookDeliveryJob chamava WebhookDelivery.entregar e descartava o retorno. Como o serviço capturava tudo, logava e devolvia false, o Active Job dava a entrega por concluída em qualquer cenário — endpoint fora do ar, timeout, 5xx. Tudo virava um aviso no log que ninguém reprocessava.

O retorno passa a ser a decisão

Situação	Resultado	O job…
2xx	true	encerra
assinatura pausada/excluída, URL reprovada na checagem de SSRF, 4xx, erro de TLS	false	encerra sem gastar tentativa
erro de rede, 429, 5xx	levanta FalhaTemporaria	reagenda, backoff polinomial, 5 tentativas

FalhaTemporaria é a única exceção que escapa do serviço, de propósito — é exatamente o sinal que o retry_on observa.

Três decisões que valem explicar

Erro de TLS não repete. Certificado expirado, inválido ou com nome errado é configuração do outro lado. Repetir cinco vezes não conserta e mantém uma assinatura quebrada parecendo viva. Fica de fora de ERROS_TEMPORARIOS deliberadamente, com o motivo no código.

Erro inesperado também não repete. Se algo estourar que não seja instabilidade do outro lado, é bug nosso — repetir não conserta e atrasa o diagnóstico. Vai para o log em nível error (antes era warn) e encerra.

O bloco do retry_on existe porque a alternativa é silêncio. Sem ele, esgotadas as tentativas a entrega sumiria sem rastro — o mesmo problema desta issue, só que adiado da primeira falha para a quinta.

Uma sutileza que quase reintroduziu o bug

O rescue FalhaTemporaria precisa vir antes do rescue StandardError. Como ela herda dele, sem essa cláusula a exceção levantada na avaliação da resposta seria engolida pelo rescue genérico e viraria de novo o false silencioso que este PR elimina. Está comentado no código, porque é o tipo de linha que alguém remove achando redundante.

Mudança de ambiente que veio junto

config.active_job.queue_adapter = :test no ambiente de teste. Sem isso valia o :async, que roda o job de verdade numa thread de fundo durante o teste — contra o mesmo banco, dentro de uma transação que o RSpec vai desfazer, e com chance de tentar rede real via WebhookDelivery.

Hoje isso quase nunca disparava, porque os specs de dispatcher dublam perform_later. Mas era acidente, não desenho. E é o adapter :test que permite verificar o reagendamento sem esperar backoff real.

O que este PR não resolve

O adapter em produção continua sendo o :async em memória, então as tentativas reagendadas também se perdem num restart — é a #77. O retry aqui cobre a instabilidade curta, que é a maioria dos casos, e vale independentemente do backend: mesmo com Solid Queue, um job que nunca levanta exceção nunca seria repetido. Registrado no README.

Verificação

	resultado
RuboCop	105 arquivos, 0 offenses
Zeitwerk check	All is good!
RSpec	375 exemplos, 0 falhas (eram 366; 9 novos)

Cobertura nova: cada classificação de falha verificada isoladamente (rede, timeout, 5xx, 429, TLS, erro inesperado) e as três decisões do job (reagenda no temporário, não reagenda no definitivo nem no sucesso).

Resolvi as duas ofensas de RuboCop que a mudança gerou sem abrir exceção no .rubocop.yml: Class.new(StandardError) virou declaração de classe, e o método que avalia a resposta passou a se chamar entregue?, que é o que ele de fato responde.

🤖 Generated with Claude Code