--- title: "Un timeout no demuestra que la acción falló" slug: "timeout-nao-e-falha" date: "2026-10-15" publishedAt: "2026-10-15T06:02:00-03:00" author: "Rodrigo Jorge" summary: "El agente no recibió la respuesta. Eso no significa que el servicio no haya ejecutado la solicitud. Antes de repetir una acción, la integración debe resolver cómo manejar esa incertidumbre." origem: "Análisis" status: "published" --- **Rodrigo Jorge** · Preparado el 15 de octubre de 2026 a las 06:02 (hora de Brasilia, UTC-3). Hora de publicación por confirmar. Un agente solicita crear un entorno aislado para analizar un archivo sospechoso. El servicio acepta la solicitud, pero la respuesta no llega. El agente recibe un timeout y vuelve a intentarlo. ¿Cuántos entornos se crearon? El escenario es hipotético. La respuesta depende del contrato de la API y de cómo la integración repitió la solicitud. Si cada intento representa una nueva creación, el retry puede generar otro entorno. Con una deduplicación adecuada, los intentos pueden corresponder a la misma operación. Como CISO, preguntaría eso antes de discutir si el modelo interpretó bien el archivo. La decisión puede ser correcta y aun así producir, durante la ejecución, un efecto que nadie autorizó dos veces. Malcolm Featonby aborda precisamente esta incertidumbre en la Amazon Builders' Library: qué ocurre cuando se pierde una respuesta y cómo usar identificadores de solicitud para que los retries sean seguros. El problema es anterior a los agentes de IA. Cuando deciden volver a llamar una herramienta, deben respetar su contrato. ## ¿Repetir la solicitud o crear otra? En la documentación de EC2, `RunInstances` figura entre las acciones que aceptan un `client token` para garantizar idempotencia. Repetir la solicitud con el mismo token y los mismos parámetros, dentro del alcance previsto, evita una nueva ejecución. Ese alcance importa: la garantía puede ser regional o por Availability Zone. Usar el mismo token en otro alcance puede crear recursos adicionales. Esto documenta un mecanismo específico. No demuestra que todas las API que utiliza un agente ofrezcan la misma protección, ni que un retry decidido por el modelo conserve el token que usó la integración. Propongo que identificar la operación sea responsabilidad de la integración. El identificador debe mantenerse en todos los intentos de la misma operación, incluso si el proceso se reinicia. Cambiar la clave en cada llamada puede convertir un reintento en una solicitud nueva. Reutilizarla para una intención distinta también es un error. Antes de habilitar retries automáticos, el equipo debe verificar en qué ámbito la API reconoce duplicados, cuánto tiempo conserva esa información y qué ocurre si cambian los parámetros. Un campo llamado `request_id` puede servir solo para rastreo. El nombre no demuestra idempotencia. [Ver el diagrama: la acción puede completarse antes de que aparezca el timeout](/assets/artigos/timeout-nao-e-falha-es.svg). Secuencia hipotética, sin tiempos ni resultados medidos. Cuando la API no ofrece esa garantía, consultar el estado de la operación puede ayudar. Pero una consulta sin resultados también requiere interpretación: ¿el estado ya debería ser visible? Si todavía no se puede determinar qué ocurrió, quizá el flujo deba detenerse para reconciliar el estado en lugar de enviar otra solicitud. Esa decisión depende del costo de duplicar la acción y del costo de esperar. La prueba que pediría es perder deliberadamente la respuesta después de que el servicio acepte la solicitud, en un laboratorio, y observar el siguiente intento. No basta con contar llamadas: hay que contar los efectos en el servicio de destino y comprobar qué ocurre después de reiniciar la integración. Un retry autorizado debe seguir siendo la misma operación autorizada. Si la integración no puede demostrarlo, el timeout debe quedar registrado como resultado desconocido hasta que haya evidencia para resolver la incertidumbre. ### Referencias - [Malcolm Featonby, Amazon Builders' Library: Making retries safe with idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/), consultado el 15 de octubre de 2026. - [AWS EC2: Ensuring idempotency in Amazon EC2 API requests](https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-idempotency.html), documentación consultada el 15 de octubre de 2026.