Estoy llamando a una API externa utilizando el nodo HTTP Request. La API a veces tarda un tiempo en responder, así que habilitué la opción de reintentos. El problema es que algunas solicitudes terminan creando registros duplicados en el sistema externo.
Describe el problema/error/pregunta
Del historial de ejecución, parece que la solicitud se reintenta incluso aunque la primera solicitud puede haber llegado a la API. ¿Hay alguna manera de evitar esto sin desactivar completamente los reintentos?
¿Cuál es el mensaje de error (si lo hay)?
Por favor, comparte tu flujo de trabajo
(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)
Comparte el resultado devuelto por el último nodo
Información sobre tu configuración de n8n
- Versión de n8n: 1.123.x
- Base de datos (predeterminado: SQLite):
- Configuración n8n EXECUTIONS_PROCESS (predeterminado: own, main):
- Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio):
- Sistema operativo:
Hola @Amidu_Louis, ¡bienvenido a la comunidad! Sí, puedes mantener los reintentos. Los duplicados provienen de cómo funciona «Retry On Fail» (Reintentar si falla): vuelve a ejecutar todo el nodo, no solo la solicitud que falló. El nodo HTTP Request envía cada elemento que recibió, y si uno de ellos genera un error, el nodo falla y el reintento envía todos de nuevo, incluyendo los que ya crearon su registro.
Pon el nodo HTTP Request dentro de un «Loop Over Items» (Bucle sobre elementos) con Batch Size (Tamaño de lote) 1, para que cada ejecución del nodo maneje un elemento y un reintento solo reenvíe ese. Si la API admite una clave de idempotencia (Stripe la llama encabezado Idempotency-Key), también envía una que se mantenga igual en los reintentos, como un ID de tus propios datos, para que una solicitud que agotó el tiempo después de llegar a la API tampoco pueda crear un segundo registro.
También vale la pena revisar Options > Timeout (Opciones > Tiempo de espera) en el nodo. Una vez que añades esa opción, por defecto es 10 segundos, así que una respuesta más lenta cuenta como un fallo y se reintenta.
El bucle de un solo elemento solo ayuda si varios elementos de entrada llegan al nodo HTTP Request y un reintento está reproduciendo hermanos exitosos. No resuelve el caso de tiempo de espera en tu pregunta: la misma solicitud puede haber creado el registro antes de que se perdiera la respuesta
Primero verificaría si el destino acepta una clave de idempotencia estable. Si no, mantén una referencia de operación derivada del negocio y reconcilia el destino antes de reintentar un resultado ambiguo. Una marca local “seen” por sí sola no puede probar que la escritura remota falló
Una cosa que añadir a las sugerencias de Loop Over Items + idempotency: para un POST no idempotente, no usaría en absoluto el Retry On Fail integrado del nodo HTTP Request. No puede distinguir un timeout (donde la solicitud puede haber creado ya el registro) de un fallo limpio.
En su lugar, configura ese nodo en On Error > Continue (usando salida de error) y construye tu propio reintento: si el estado es 429, o falló la conexión antes de enviar, Espera unos segundos e intenta de nuevo una o dos veces. Si se agotó el tiempo, primero haz una búsqueda GET usando tu propia referencia única para ese registro, y solo re-POST si no está ahí. Trata un timeout como desconocido, no como fallido. Aumentar Options > Timeout en el nodo ayuda, pero no elimina esa ambigüedad.
Hola @Amidu_Louis, espero que estés bien
Esto puede suceder cuando la API procesa la solicitud pero n8n no recibe la respuesta a tiempo. El reintento envía entonces la misma solicitud de nuevo. Si la API admite claves de idempotencia, utiliza una clave única para cada operación para que las solicitudes repetidas no creen registros duplicados. Si no es así, necesitarás verificar si el registro ya existe antes de crearlo
Los reintentos son útiles, pero para solicitudes POST que crean datos, no siempre son seguros por sí solos
Una adición a la respuesta de Deepankar: después de aumentar el timeout, abre una de las ejecuciones duplicadas y observa el error del primer intento. Si es un timeout/ECONNABORTED en lugar de un 5xx, es probable que la solicitud llegara a la API, y reintentar a ciegas siempre arriesgará un duplicado. En ese caso, desactiva Retry On Fail, establece On Error en “Continue (using error output)”, y vuelve al bucle solo en errores donde la solicitud claramente nunca llegó (429, ECONNREFUSED). Pequeña sugerencia: el título menciona el nodo Code, así que editarlo ayudará a otros a encontrar esto.