APRENDER. PRATICAR. EVOLUIR.Desenhar o caminho de uma operação
Uma confirmação em falta não significa necessariamente que o pagamento não aconteceu. Num serviço fictício, o evento entra, a função cria o lançamento e a notificação final falha. Repetir tudo sem conhecer o estado pode criar um segundo lançamento. Desenha separadamente aceitação pelo transporte, invocação, efeito persistente e confirmação. Define uma identidade de negócio que se mantenha entre tentativas e um mecanismo persistente que proteja o efeito, incluindo concorrência. Lambda assíncrono pode repetir um evento mesmo após sucesso. Um identificador novo em cada tentativa resolve rastreabilidade da tentativa, mas não a unicidade da operação. Regista ambos e explica a relação no diagnóstico.
Capturar falhas antes e depois do handler
Um backlog pode envelhecer até eventos expirarem sem entrar no handler. Por isso, ausência de stack traces não prova que todas as operações correram. Acompanha idade, descarte, execução e resultado. Um destino on-failure pode conservar o registo de invocação com pedido e resposta; uma DLQ guarda o evento original e atributos de erro. São contratos diferentes. Testa ainda o caminho de captura: DestinationDeliveryFailures significa que a informação esperada pode não ter chegado ao destino. Verifica permissões, tipos e limites antes de confiar na fila de investigação. Uma falha no mecanismo de diagnóstico tem impacto próprio e deve constar do relatório de incidente.
Conter e restaurar com um inventário de trabalho
Definir reserved concurrency a zero pode ser uma medida de contenção autorizada. Para invocações assíncronas novas com captura de falhas configurada, o trabalho é encaminhado para DLQ ou destino on-failure sem retries. Restaurar capacidade não significa que esse trabalho reapareça automaticamente na execução normal. Antes da mudança, identifica onde irão parar eventos e quem os recupera; depois, reconcilia entradas, efeitos e pendências. O mesmo cuidado aplica-se a limites de capacidade: aumentar concorrência pode pressionar uma base de dados já degradada. Define critérios de paragem e compara idade do backlog com a capacidade efetiva do destino, em vez de usar apenas o tamanho da fila.
Preparar replay com limites verificáveis
O replay nativo EventBridge regressa ao bus de origem. Para testes isolados, desenha uma rota controlada e confirma que outras regras não produzem efeitos inesperados. Delimita tempo e regras relevantes; os eventos não têm garantia de regressar pela ordem de entrada no arquivo. O consumidor precisa de validar identidade e versão de negócio. replay-name permite reconhecer a reprodução, mas não é uma chave de unicidade da operação. O arquivo conserva eventos segundo a sua retenção; terminar o replay não os apaga nem prova conclusão de todos os consumidores. No caso de liquidações, compara identificadores, montantes esperados e estados confirmados, usando dados fictícios no exercício.
Recuperar batches sem confirmar trabalho por executar
No consumo Lambda de SQS, a resposta parcial exige ReportBatchItemFailures no mapping e o formato correto devolvido pelo handler. Uma exceção global faz falhar o batch inteiro. Para FIFO, interrompe na primeira falha e devolve identificadores falhados e ainda não processados. No exercício, A termina, B falha e C/D ficam por executar; a resposta de recuperação inclui B/C/D. O modelo local torna essa decisão visível, mas não é um handler AWS pronto a instalar. Não implementa persistência, concorrência nem a resposta JSON do serviço. Usa-o para discutir quais os efeitos já confirmados e quais os identificadores que precisam de outra tentativa.
Aceitar a recuperação pelo resultado
A configuração exige que o timeout da função não exceda a visibilidade da mensagem. A recomendação AWS reserva mais margem: seis vezes o timeout, mais a batch window. Com 20 e 5 segundos, isso dá pelo menos 125 segundos recomendados. Distingue recomendação e validação mínima. Respostas parciais também não reduzem automaticamente o polling quando há falhas; controla a pressão sobre o destino separadamente. Para concluir o incidente, reúne o conjunto esperado, o que terminou, o que foi repetido e o que ficou pendente ou em quarentena. A conclusão operacional depende dessa correspondência e da estabilidade observada, não apenas de uma fila vazia ou do estado COMPLETED.
# Original decision model, not an AWS handler or a production replay tool.
def fifo_review(items, first_failure):
if len(set(items)) != len(items):
raise ValueError("Exercise identifiers must be unique")
if first_failure is None:
return {"completed": items[:], "retry": []}
if first_failure not in items:
raise ValueError("Failure must belong to the batch")
boundary = items.index(first_failure)
return {"completed": items[:boundary], "retry": items[boundary:]}
assert fifo_review(["A", "B", "C", "D"], "B") == {
"completed": ["A"], "retry": ["B", "C", "D"]}
assert fifo_review(["A"], "A") == {"completed": [], "retry": ["A"]}
assert fifo_review(["A", "B"], None) == {"completed": ["A", "B"], "retry": []}
assert fifo_review([], None) == {"completed": [], "retry": []}
A terminou, B falhou e C/D dependem da ordem FIFO. A recuperação repete B/C/D, conserva evidência do sucesso de A e reconcilia qualquer efeito parcial de B.
Armadilhas comuns
Mudar a identidade a cada tentativa; confundir DLQ assíncrona com recuperação SQS; processar FIFO depois da primeira falha; fechar o incidente apenas com COMPLETED.
Tópicos relacionados: Sinais fiáveis e lacunas de observabilidade
Repetir entrega só é recuperação quando preserva identidade, ordem necessária e efeitos já aplicados, com reconciliação posterior.
Referência: Lambda asynchronous invocation errors · DOP-C02