Timeouts y reintentos: el riesgo de duplicar operaciones

Una automatización pide a un proveedor que cree un envío. Pasan unos segundos, la conexión se corta y el panel marca error. El reintento parece obvio. Salvo por un detalle: el proveedor puede haber creado el envío antes de que se perdiera la respuesta.

Este escenario es hipotético, pero describe una dificultad básica de los sistemas distribuidos. Un timeout acredita que no recibimos una respuesta a tiempo. No demuestra que la operación no haya ocurrido. Cuando tratamos ambas cosas como equivalentes, un mecanismo pensado para recuperar el servicio puede repetir sus efectos.

El problema no desaparece porque el proceso tenga una interfaz cómoda, se ejecute en una plataforma de automatización o lo dirija un agente de IA. En cuanto una petición sale de nuestro sistema, necesitamos distinguir lo que ocurrió de lo que sabemos que ocurrió.

La incertidumbre merece un estado propio

Muchos paneles solo ofrecen éxito o error. Son suficientes para algunas tareas, pero pobres para representar una escritura remota cuyo resultado se desconoce. Si guardamos todo timeout como «fallido», el siguiente componente puede interpretar que tiene vía libre para repetir.

La diferencia se ve en una escena sencilla. Un mensaje que nunca salió de la cola local y otro que salió, llegó al proveedor y perdió su confirmación pueden acabar pintados del mismo color. Sin embargo, el primero necesita envío y el segundo necesita averiguación. La misma apariencia visual esconde dos decisiones operativas diferentes.

En Making retries safe with idempotent APIs, Malcolm Featonby explica este dilema a través de la creación de recursos en AWS. Una respuesta ausente deja al cliente sin saber si el recurso existe. El artículo describe el uso de un identificador aportado por el cliente para expresar la intención y reconocer repeticiones de una misma solicitud.

La distinción importante es entre identidad de la operación e igualdad de sus datos. Dos envíos al mismo destino pueden ser un duplicado accidental o dos pedidos legítimos. Comparar solamente el contenido no nos permite decidir cuál de las dos cosas está sucediendo.

Qué ofrece la idempotencia y dónde termina

Una operación idempotente puede repetirse sin añadir un nuevo efecto al que corresponde a la misma intención. El alcance concreto de esa promesa depende del contrato del servicio. Conviene separar esa propiedad de la entrega del mensaje: recibir una solicitud varias veces puede ser compatible con producir un solo efecto.

Stripe ofrece un ejemplo documentado de esos límites. Su API de peticiones idempotentes conserva el código y cuerpo de la primera respuesta para una clave, incluidos errores 500. Las claves pueden eliminarse cuando tienen al menos 24 horas y reutilizar una clave ya eliminada crea una petición nueva. También contrasta los parámetros para evitar reutilizaciones incompatibles.

Ese plazo pertenece a Stripe y no debe extrapolarse a cualquier integración. Su interés aquí es mostrar que «hay idempotencia» deja preguntas abiertas. Una recuperación que llega días después necesita conocer qué memoria conserva el receptor. La clave que protegía ayer puede no conservar la misma protección cuando retomamos una cola antigua.

La garantía también tiene una frontera. Que un servicio reconozca una solicitud repetida no acredita que todas las acciones posteriores compartan esa identidad. Un flujo puede evitar crear dos pedidos y, aun así, enviar dos notificaciones desde otro componente que reaccione dos veces. El efecto que prometemos no duplicar debe estar nombrado.

Un mapa de certeza del efecto

Propongo el mapa de certeza del efecto como herramienta de conversación entre producto y operación. Es una síntesis propia, no un protocolo ni una garantía matemática. Su objetivo es evitar que «reintentar» se convierta en la respuesta automática para estados diferentes.

No iniciado, con evidencia

Sabemos que la petición no salió o que fue rechazada antes de comenzar. Puede plantearse un nuevo intento si la causa se ha resuelto.

Resultado desconocido

La solicitud pudo producir efecto. Hace falta conciliación con el receptor o una repetición cubierta por su contrato de idempotencia. Crear una intención nueva aumenta el riesgo de duplicado.

Efecto confirmado

Existe una referencia verificable del resultado. Un problema posterior de visualización o notificación no justifica repetir la operación original.

Efecto parcial

Unas acciones están confirmadas y otras pendientes. La recuperación debe decidir sobre cada una. Repetir el flujo completo puede volver a ejecutar las que ya terminaron.

En nuestro envío hipotético, un timeout sitúa la operación en resultado desconocido. Si el proveedor permite consultar una referencia estable, esa consulta puede aclarar qué ocurrió. Si su contrato permite repetir la misma intención con seguridad, esa vía puede recuperar la respuesta. Si no ofrece ninguna de las dos capacidades, el sistema tiene una limitación real que debe mostrarse.

Conciliar tampoco significa preguntar una vez, no encontrar nada y declarar que no ocurrió. Una consulta puede ir contra una vista que todavía no refleja la escritura. La confianza depende del comportamiento documentado del receptor y de qué identifica exactamente la referencia buscada.

El indicador de éxito puede ocultar el problema

Consideremos un ejemplo ilustrativo: 1.000 solicitudes para crear envíos, diez respuestas perdidas y ocho operaciones que el proveedor sí llegó a completar entre esas diez. Si repetimos las diez como nuevas solicitudes y todas prosperan, podríamos acabar con 1.008 envíos. El panel local podría mostrar 1.000 tareas finalmente correctas.

El cálculo no estima una tasa real de fallos. Muestra una diferencia de denominadores: tareas cerradas en nuestro sistema frente a efectos producidos fuera. Mejorar el primer indicador no garantiza mejorar el segundo.

Por eso una revisión profesional necesita mirar también operaciones sin resolver, efectos duplicados y tiempo hasta aclarar resultados ambiguos. Son métricas que ayudan a decidir si la automatización ahorra trabajo o desplaza sus errores hacia atención al cliente.

El tiempo entre intentos y el número máximo de repeticiones siguen importando. Reducen insistencia y consumo, pero no aportan por sí solos la identidad que falta. Esperar más antes de crear un segundo envío no lo convierte en el primero.

Qué debería ver quien opera el proceso

Una interfaz útil puede mostrar «resultado pendiente de confirmar», la referencia conocida y qué comprobación falta. El botón de reintento necesita un significado inequívoco: recuperar la respuesta de la misma operación o crear otra. Mezclarlos bajo una etiqueta cómoda hace que el operador asuma una decisión que la pantalla no explica.

Cuando el dato pasa de mostrarse a ejecutar acciones, esta claridad forma parte del producto. No es un detalle reservado al equipo de integración. La persona que atiende una incidencia necesita saber si está esperando una confirmación, corrigiendo un rechazo o autorizando un efecto nuevo.

Una automatización merece confianza cuando sabe continuar y también cuando sabe conservar una duda sin convertirla en otra orden. Antes de celebrar que todos los errores se reintentan solos, conviene comprobar qué entiende el sistema por «error» y qué evidencia exige para volver a actuar.