---
title: "O timeout não prova que a ação falhou"
slug: "timeout-nao-e-falha"
date: "2026-10-15"
publishedAt: "2026-10-15T06:02:00-03:00"
author: "Rodrigo Jorge"
summary: "O agente não recebeu a resposta. Isso não significa que o serviço deixou de executar o pedido. Antes de repetir uma ação, a integração precisa tratar essa incerteza."
origem: "Análise"
status: "published"
---

**Rodrigo Jorge** · Preparado em 15 de outubro de 2026, às 06:02 (horário de Brasília, UTC-3). Horário de publicação a confirmar.

Um agente solicita a criação de um ambiente isolado para analisar um arquivo suspeito. O serviço aceita o pedido, mas a resposta não chega. O agente recebe um timeout e tenta de novo.

Quantos ambientes foram criados?

Esse cenário é hipotético. A resposta depende do contrato da API e de como a integração repetiu o pedido. Se cada tentativa representar uma nova criação, o retry pode gerar outro ambiente. Se houver deduplicação adequada, as tentativas podem corresponder à mesma operação.

Como CISO, eu perguntaria isso antes de discutir se o modelo interpretou bem o arquivo. A decisão pode estar correta e a execução produzir um efeito que ninguém autorizou duas vezes.

A Amazon Builders' Library, em texto de Malcolm Featonby, discute justamente a incerteza causada pela perda de uma resposta e o uso de identificadores de pedido para tornar retries seguros. O problema antecede agentes de IA. Eles precisam respeitar o contrato da ferramenta quando decidem chamá-la novamente.

## Repetir o pedido ou criar outro?

Na documentação do EC2, `RunInstances` está entre as ações que aceitam um `client token` para idempotência. Repetir com o mesmo token e parâmetros, dentro do escopo previsto, evita nova execução. Esse escopo importa: a garantia pode ser regional ou por Availability Zone. Usar o mesmo token em outro escopo pode criar recursos adicionais.

Isso documenta um mecanismo específico. Não demonstra que toda API usada por um agente ofereça a mesma proteção, nem que o retry feito pelo modelo preserve o token usado pela integração.

Minha proposta é tratar a identificação da operação como responsabilidade da integração. O identificador deve persistir nas tentativas da mesma operação, inclusive quando houver reinício do processo. Trocar a chave a cada chamada pode transformar uma repetição em um pedido novo. Reutilizá-la para uma intenção diferente também é erro.

Antes de habilitar retry automático, a equipe precisa conferir onde a API reconhece duplicatas, por quanto tempo guarda essa informação e o que acontece se os parâmetros mudarem. Um campo chamado `request_id` pode servir apenas para rastreamento. O nome não comprova idempotência.

[Ver o diagrama: a ação pode terminar antes de o timeout aparecer](/assets/artigos/timeout-nao-e-falha-pt.svg). Sequência hipotética, sem tempos ou resultados medidos.

Quando a API não oferece essa garantia, consultar o estado da operação pode ajudar. Mas uma consulta vazia também exige interpretação: o estado já deveria estar visível? Se ainda não é possível saber o que ocorreu, o fluxo pode precisar parar para reconciliação em vez de enviar outro pedido. Essa decisão depende do custo de duplicar a ação e do custo de esperar.

O teste que eu pediria é perder deliberadamente a resposta depois de o serviço aceitar o pedido, em laboratório, e observar a tentativa seguinte. Não basta contar chamadas: é preciso contar efeitos no serviço de destino e verificar o comportamento depois de reiniciar a integração.

Um retry autorizado deve continuar sendo a mesma operação autorizada. Se a integração não consegue demonstrar isso, o timeout precisa permanecer registrado como resultado desconhecido, até que haja evidência para resolver a incerteza.

### Referências

- [Malcolm Featonby, Amazon Builders' Library: Making retries safe with idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/), consultado em 15 de outubro de 2026.
- [AWS EC2: Ensuring idempotency in Amazon EC2 API requests](https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-idempotency.html), documentação consultada em 15 de outubro de 2026.