Una solicitud entra en el CRM. La integración intenta crear una orden de trabajo en el programa de gestión, pero se agota el tiempo de espera y aparece «error». Alguien pulsa repetir. Poco después, el equipo encuentra dos órdenes para el mismo encargo.
Es una situación ilustrativa, no un caso de cliente de NorteIA. El problema es que recibir un error no siempre permite saber si la acción llegó a ejecutarse. Antes de recuperar una automatización hay que distinguir lo que está confirmado, lo que no se hizo y lo que todavía no se puede comprobar.
Un fallo no significa que todo siga como antes
En el ejemplo hay tres pasos: registrar la solicitud, crear la orden y avisar al responsable. Cada uno puede terminar de forma distinta. Si falla el aviso, volver a crear la orden no resuelve el problema y puede añadir otro.
La Amazon Builders’ Library explica este caso: un servicio puede completar una operación y perderse la respuesta. Repetirla sin protección puede producir efectos adicionales. Una operación idempotente permite repetir la misma petición sin repetir esos efectos.
Para organizar la recuperación proponemos registrar el estado de cada paso, la referencia de la solicitud y la evidencia del resultado. «Pendiente de comprobar» debe ser un estado visible, con responsable. No lo conviertas automáticamente en «no ejecutado».
Una tabla para decidir el siguiente paso
Esta tabla es una propuesta operativa de NorteIA. Adáptala a las acciones y a las garantías de tus sistemas. El mensaje de error ayuda a investigar; la decisión depende también de lo que ocurrió en el destino.
| Situación observada | Qué comprobar | Decisión de recuperación |
|---|---|---|
| Falta un dato obligatorio y el destino rechaza la solicitud sin procesarla. | El registro de rechazo y el campo que falta. | Pedir o corregir el dato. Repetir la misma petición incompleta no resolverá el fallo. |
| Se interrumpe la conexión y no llega una respuesta. | Si existe el resultado asociado a la referencia y si hay una operación aún en curso. | Comprobar el estado o usar un reintento protegido por la garantía del destino. Si no se puede resolver la duda, revisión humana. |
| La orden está creada, pero el aviso al responsable no salió. | Identificador de la orden y estado del envío. | Recuperar solo el aviso pendiente. Si el envío también es incierto, comprobarlo antes de repetirlo. |
| El servicio limita temporalmente las peticiones. | La respuesta del proveedor y las condiciones para volver a intentar. | Esperar y aplicar un número limitado de intentos, siempre que repetir sea seguro. |
| El acceso está denegado o la conexión perdió autorización. | Qué permiso o conexión necesita atención y quién puede resolverlo. | Detener el bucle y avisar al responsable. Reanudar tras corregir el acceso, sin ampliar permisos automáticamente. |
La documentación de Microsoft sobre el patrón de reintentos distingue fallos transitorios de otros que requieren corregir su causa. También advierte de que reintentar de forma agresiva puede empeorar la saturación. Define esperas, un límite de intentos y qué ocurre al alcanzarlo.
Identificar la operación, no solo al cliente
Conserva una referencia estable para cada acción que deba ocurrir una sola vez: por ejemplo, la creación de la orden de una solicitud concreta. El nombre del cliente no basta; ese mismo cliente puede encargar dos trabajos legítimos.
Cuando una API ofrece claves de idempotencia, hay que respetar su contrato: alcance, vigencia y tratamiento de cambios en la petición. Reutiliza la identidad de la misma operación al recuperarla; una operación nueva necesita su propia identidad. La protección debe estar implementada en el destino o en una integración capaz de garantizarla: escribir una referencia en un campo no evita duplicados por sí solo.
Consultar antes de crear tampoco garantiza el resultado si dos ejecuciones pueden actuar a la vez. Si no existe una protección comprobada frente a esa concurrencia, deja la recuperación controlada por una persona. Evita que alguien procese manualmente un encargo mientras sigue activo un reintento automático del mismo paso.
Ejemplo: doce solicitudes, tres situaciones distintas
Imagina un lote de 12 solicitudes ficticias. En este ejemplo hipotético, las trazas confirman nueve recorridos completos y dos rechazos previos a crear la orden. En el último recorrido se perdió la respuesta del programa de gestión. Son cantidades inventadas para explicar el procedimiento, no resultados medidos.
| Situación inicial | Solicitudes | Actuación en este ejemplo |
|---|---|---|
| Orden y aviso confirmados. | 9. | Conservar como completadas. No ejecutar otra vez. |
| Rechazo confirmado antes de crear la orden. | 2. | Corregir el dato, crear cada orden y comprobar su aviso. |
| Resultado de creación desconocido. | 1. | Investigar por su referencia. Se encuentra la orden ya creada; queda recuperar el aviso que consta como no enviado. |
El recuento inicial es 9 + 2 + 1 = 12 solicitudes. La comprobación localiza diez órdenes existentes: nueve confirmadas desde el principio y una cuya respuesta se había perdido. Solo hay que crear dos órdenes nuevas: 10 + 2 = 12. Para cerrar los doce recorridos también se comprueba el aviso correspondiente a cada uno.
Encontrar un registro parecido no bastaría para resolver el caso incierto: debe corresponder a la misma operación. Si no se puede identificar, seguirá pendiente. El objetivo no es dejar todos los indicadores en verde a cualquier precio.
Probar la recuperación antes del siguiente incidente
En un entorno de pruebas, provoca una pérdida de respuesta después de crear la orden. Al recuperar el recorrido debe seguir existiendo una sola orden para esa operación. Comprueba además dos solicitudes legítimas del mismo cliente: deben poder generar dos órdenes distintas.
El comprobador también necesita una prueba negativa. Introduce deliberadamente un duplicado ficticio y verifica que lo señala; de otro modo, un resultado «sin duplicados» podría no estar comprobando nada. Añade un caso con el destino inaccesible para verificar que el proceso agota sus intentos y deja el problema asignado, sin desaparecer de la vista del equipo.
Para revisar la continuidad, cuenta solicitudes terminadas, casos pendientes de comprobar, antigüedad de esos casos y duplicados detectados. El número de intentos exitosos no equivale al número de encargos completados.
En NorteIA ayudamos a conectar procesos y sistemas desde A Coruña para empresas de Galicia. Si hoy recuperáis fallos pulsando «repetir» sin saber qué se ejecutó, podemos revisar las integraciones y sus criterios de recuperación para que el equipo tenga un siguiente paso comprobable.