4. El modelo de ejecución en n8n 2.0

Descripción

Al terminar esta lección vas a poder explicar qué pasa, por dentro, cuando algo dispara un workflow: qué es una ejecución, cómo fluye un item de nodo en nodo, dónde ves lo que ocurrió, y —lo más importante para esta guía— qué sucede exactamente cuando reintentas. Vas a entender por qué un reintento vuelve a ejecutar nodos, que es el mecanismo preciso que convierte un reintento inocente en un cobro duplicado. Y vas a conocer los cambios que trajo n8n 2.0, en particular el aislamiento del nodo de código con los task runners, y qué de eso afecta tu forma de diseñar.

Esto importa porque hasta ahora hablamos del duplicado como algo que "pasa", sin ver la maquinaria. Esta lección es la maquinaria. Cuando entiendas que una ejecución es una corrida completa del workflow y que reintentar significa correr esa maquinaria otra vez, el problema del duplicado deja de ser una idea abstracta y se vuelve algo que puedes señalar con el dedo: "aquí, en este reintento, este nodo se ejecuta por segunda vez y vuelve a cobrar".

Conexión con el módulo: en la lección 3 te llevaste el criterio —¿es seguro de repetir cada efecto?— pero "repetir" era todavía una palabra abstracta. Esta lección la vuelve concreta mostrándote los tres momentos en que un efecto se repite: el reintento de un nodo, el reintento de una ejecución completa, y el doble disparo (que es la lección 5). A partir de aquí, cuando digamos "se ejecuta dos veces", vas a saber exactamente qué maquinaria está corriendo dos veces. La lección 5 toma este modelo y le agrega la razón por la que los disparadores mismos entregan duplicados; la lección 6 usa este modelo para mapear los modos de falla.

Una nota de honestidad sobre versiones. n8n cambia rápido, y el detalle exacto de su motor de ejecución evoluciona entre versiones. Lo que sigue describe el modelo conceptual de n8n 2.0 y está redactado para que sea cierto a nivel de concepto aunque un nombre de botón o un límite numérico cambie. Donde un dato es específico y verificable, lo marco. Donde no puedo confirmarlo contra la documentación oficial, te digo que lo verifiques en tu propia instancia. La regla de esta guía es no inventar comportamientos de n8n: cuando dude, enseño el concepto y te mando a comprobar.

Qué es una ejecución

Empecemos por la palabra que vamos a usar cientos de veces.

Una ejecución (en inglés, execution) es una corrida completa de un workflow, de principio a fin, disparada por un evento. Cuando algo dispara tu workflow —un webhook que recibe un pedido, un temporizador que se cumple, un clic en "ejecutar"— n8n crea una ejecución: toma los datos del disparo, los pasa por el primer nodo, luego por el siguiente, y así hasta el final. Esa corrida entera, con todos sus nodos y todos sus datos, es una ejecución.

Piénsalo como una orden en una cocina. Cada vez que entra una comanda —"una mesa pidió el plato del día"— la cocina abre una orden nueva y la lleva de estación en estación: primero el que corta, luego el que cocina, luego el que emplata. Esa orden concreta, con su papel, su recorrido y su resultado, es una ejecución. Si entran tres comandas iguales, hay tres órdenes, cada una con su propio papel y su propio recorrido, aunque el plato sea el mismo.

Aquí está el primer hecho que sostiene toda la guía, y quiero que lo fijes:

Cada disparo crea una ejecución. Un disparo, una ejecución. Dos disparos, dos ejecuciones.

Esto suena obvio, pero tiene una consecuencia enorme. Si el mismo pedido dispara el webhook dos veces —por un reintento del proveedor, por ejemplo— n8n no ve "el mismo pedido llegando otra vez". n8n ve dos disparos, y crea dos ejecuciones independientes. Cada una arranca desde cero, sin saber que la otra existe. Cada una corre los seis nodos de order-triage. Cada una crea su registro, hace su cobro, manda su correo. n8n no tiene, por sí solo, ninguna memoria de que ya procesó ese pedido: para eso tendrías que dársela tú, y ese es el Módulo 4.

Esta es exactamente la razón por la que el duplicado es tan fácil de producir: la unidad natural de n8n es el disparo, no el pedido de negocio. Tú piensas en pedidos ("este pedido ya lo procesé"); n8n piensa en disparos ("me dispararon, ejecuto"). Cerrar esa brecha —enseñarle a n8n a pensar en pedidos— es buena parte del trabajo de la guía.

Piénsalo con una recepcionista que anota cada visita en una libreta. Si la misma persona entra, sale a buscar algo al auto y vuelve a entrar, la recepcionista anota dos visitas —porque su unidad es "alguien cruzó la puerta", no "personas distintas que vinieron hoy"—. No se equivoca: hace su trabajo, que es registrar cada cruce. Para saber que fue la misma persona dos veces, necesitaría comparar algún dato —el nombre, una identificación— contra lo que ya anotó. n8n es esa recepcionista: registra cada cruce de la puerta como una ejecución, y para reconocer que dos ejecuciones son "la misma persona" necesita que tú le des el dato a comparar (el event_id) y el lugar donde llevar la cuenta (el ledger del Módulo 4). Sin eso, cada cruce es, para n8n, una visita nueva.

Cómo fluye un item por el workflow

Ahora bajemos un nivel, a lo que pasa dentro de una ejecución.

Ya sabes de las guías anteriores que entre nodos no viaja un dato suelto, sino una lista de items. Un item es un paquete de datos —el pedido de Cumbre, por ejemplo— y viaja de nodo en nodo. Cada nodo recibe los items del nodo anterior, hace su trabajo, y entrega items al siguiente.

Dentro de una ejecución de order-triage, el recorrido de un pedido se ve así:

Webhook          →  entrega 1 item: el pedido { event_id, order_id, amount, ... }
  ↓
Get customer     →  recibe ese item, consulta el CRM, entrega el item enriquecido con la ficha
  ↓
AI Agent         →  recibe el item, clasifica, entrega el item + { priority, category }
  ↓
Create CRM order →  recibe el item, crea el registro, entrega el item + { crm_record_id }
  ↓
Create charge    →  recibe el item, cobra, entrega el item + { charge_id }
  ↓
Send Email       →  recibe el item, manda el correo, entrega el item + { email_sent: true }

Cada flecha es un traspaso de items. Y cada nodo, cuando le llega el turno, ejecuta su acción. Esa palabra —"ejecuta su acción"— es la que importa: cuando el item llega a Create charge, ese nodo no "recuerda" si ya cobró antes; simplemente ejecuta la acción de cobrar con los datos que tiene. Si el item vuelve a llegar —en un reintento o en una segunda ejecución— el nodo vuelve a ejecutar la acción de cobrar. No hay nada en el flujo del item que diga "ojo, esto ya lo hiciste".

Vale la pena notar algo sobre las ramas. Si tu workflow se abre en varias ramas —con un If o un Switch— cada rama procesa sus items por separado, y solo se ejecutan los nodos por los que efectivamente pasa un item. Un nodo por el que no pasa ningún item no se ejecuta. Esto será relevante en la lección 6 cuando hablemos del fallo parcial: qué nodos alcanzó a ejecutar una ejecución antes de fallar determina en qué estado quedó el sistema.

Dónde ves lo que pasó: los datos de ejecución

Cada ejecución deja un registro de lo que ocurrió, y saber leerlo es una habilidad central del dueño del sistema. En n8n, ese registro vive en la lista de ejecuciones.

Cuando abres una ejecución pasada, ves:

• El estado: si terminó con éxito, si falló, o si sigue en curso.
• Qué nodos se ejecutaron y en qué orden.
• Qué datos entraron y salieron de cada nodo: los items exactos, con sus campos, tal como fluyeron.
• Dónde falló, si falló: el nodo exacto que se detuvo y el mensaje de error.

Esto es oro para el dueño del sistema, porque es donde investigas un incidente. Cuando alguien te diga "a un cliente le cobraron dos veces", tu primer movimiento va a ser abrir la lista de ejecuciones, buscar las ejecuciones de ese pedido, y ver —con tus ojos— que hubo dos ejecuciones que pasaron por Create charge. Los datos de ejecución convierten "algo salió mal" en "esto pasó, exactamente aquí".

Y guarda esta capacidad, porque es la base de una de las promesas de la guía: reproducir un bug de duplicado. En el Módulo 6 vas a usar estos datos no solo para investigar, sino para volver a correr una ejecución de forma controlada y demostrar que tu protección funciona. Esa re-ejecución controlada es lo que la guía llama, de manera informal, el motor de replay: la capacidad de tomar una ejecución que ya pasó y correrla de nuevo para estudiarla.

Reintentar: el momento en que un efecto se repite

Llegamos al corazón técnico de la lección. Reintentar es, para el dueño del sistema, la operación más delicada de todas, porque es donde un efecto se repite a propósito —con buena intención— y puede duplicar. Hay dos formas de reintentar en n8n, y conviene distinguirlas con cuidado.

Reintento de un nodo: "Retry On Fail"

n8n permite configurar un nodo para que, si su acción falla, lo intente de nuevo automáticamente antes de darse por vencido. En la configuración del nodo hay una opción de reintento al fallar —comúnmente llamada Retry On Fail— con dos parámetros:

• Cuántas veces reintentar (número máximo de intentos).
• Cuánto esperar entre intentos (una pausa en milisegundos).

Al momento de escribir esta guía, esos valores tienen topes —el máximo de intentos y la espera máxima están acotados—, y esos topes pueden cambiar entre versiones, así que verifícalos en tu instancia. Lo que importa es el concepto: cuando activas el reintento en un nodo, si la acción del nodo falla, n8n vuelve a ejecutar esa acción.

Aquí está el detalle peligroso. Imagina que activas Retry On Fail en Create charge. El nodo llama a la pasarela, la pasarela sí cobra, pero justo antes de responderte se cae la conexión. Desde el punto de vista de n8n, el nodo "falló" —no recibió confirmación—, así que reintenta: vuelve a llamar a la pasarela, que cobra otra vez. El cobro ocurrió dos veces, aunque n8n creyó que la primera había fallado. El reintento, pensado para recuperarse de un fallo, produjo un duplicado, porque no distingue entre "la acción no se hizo" y "la acción se hizo pero no me enteré".

Piénsalo como pedirle a alguien que mande una carta importante y decirle "si no te confirmo que llegó, mándala de nuevo". Si la carta llega pero la confirmación se pierde en el camino, la persona manda una segunda carta. El destinatario recibe dos. La instrucción era razonable; el resultado es un duplicado, porque "no me confirmaron" no es lo mismo que "no llegó".

Por eso el reintento automático de un nodo que hace un efecto es una herramienta de doble filo: excelente para lecturas (reintentar consultar el CRM no hace daño) y peligrosa para efectos no protegidos (reintentar un cobro puede cobrar dos veces). El Módulo 6 le dedica una lección entera a los reintentos seguros, y la condición para que un reintento sea seguro la vas a reconocer de inmediato: que el efecto sea idempotente.

Reintento de una ejecución completa

La segunda forma es volver a correr una ejecución entera desde la lista de ejecuciones. Cuando una ejecución falló, n8n te ofrece reintentarla, y —esto es un dato que conviene verificar en tu versión— suele darte dos opciones sobre qué versión del workflow usar:

• Reintentar con el workflow original: usa la versión del workflow tal como estaba cuando ocurrió la ejecución original.
• Reintentar con el workflow actual: usa la versión más reciente que tengas guardada.

La distinción entre las dos importa para depurar —si arreglaste el workflow, quizá quieras reintentar con la versión nueva— pero para nuestro tema lo crucial es lo que tienen en común: el reintento vuelve a correr los nodos. Y aquí aparece el problema que ya viste en la línea de tiempo de la lección 2: si la ejecución original alcanzó a cobrar antes de fallar en el correo, el reintento del workflow completo vuelve a pasar por el cobro y cobra de nuevo.

Este es el mecanismo exacto detrás de aquella tabla. No es magia ni un bug: es que reintentar una ejecución completa significa, literalmente, ejecutar sus nodos otra vez, y los nodos ejecutan sus acciones sin preguntar si ya se hicieron.

De aquí sale una regla práctica que el Módulo 6 formaliza, pero que ya puedes intuir: reintentar una ejecución completa solo es seguro si todos los efectos que se van a repetir son idempotentes. Si no lo son, un reintento "para arreglar" un fallo parcial puede empeorar las cosas. La alternativa —reintentar solo la parte que falló, sin repetir lo que ya se hizo— requiere que el sistema recuerde qué ya hizo, y eso es el ledger del Módulo 4.

Dos ejecuciones al mismo tiempo: la carrera

Hay un detalle del doble disparo que conviene ver ahora, porque desmonta una solución que a casi todo el mundo se le ocurre primero, y entenderlo temprano te ahorra construir algo que no funciona.

Cuando el proveedor reenvía el pedido con dos segundos de diferencia, las dos ejecuciones no corren una después de la otra de forma ordenada: pueden correr casi al mismo tiempo, solapadas. La ejecución #4471 todavía no terminó cuando la #4472 ya arrancó. Las dos están vivas a la vez, cada una avanzando por sus nodos.

Esto rompe la primera idea que surge para evitar duplicados. La idea natural es: "antes de cobrar, que el workflow revise si este pedido ya se cobró; si ya se cobró, que no cobre". Suena perfecto. Pero mira qué pasa con dos ejecuciones solapadas:

Ejecución #4471:  revisa "¿ya se cobró ORD-2041?"  →  no  →  cobra
Ejecución #4472:  revisa "¿ya se cobró ORD-2041?"  →  no  →  cobra
                  (las dos revisaron ANTES de que la otra cobrara)

Las dos ejecuciones preguntan "¿ya se cobró?" casi al mismo tiempo, antes de que cualquiera de las dos haya alcanzado a cobrar. Las dos reciben la misma respuesta: "no, todavía no". Y las dos, confiando en esa respuesta, cobran. El "revisa antes de actuar" no las salvó, porque entre revisar y actuar hubo un hueco de tiempo en el que la otra ejecución también revisó.

A este patrón peligroso —revisar el estado y luego actuar sobre esa revisión, con un hueco en medio donde otra ejecución puede colarse— se le llama "verificar y luego actuar" (en inglés, check-then-act), y es una de las trampas más importantes de toda la guía. Tiene una lección entera dedicada en el Módulo 2, porque la solución ingenua a los duplicados casi siempre cae en ella.

No necesitas la solución todavía. Lo que quiero que te lleves de aquí es una advertencia que te va a ahorrar tiempo: cuando llegues al Módulo 2 y quieras evitar duplicados, tu primer instinto va a ser "reviso y luego cobro", y ese instinto tiene un agujero. El modelo de ejecución que acabas de aprender —dos disparos, dos ejecuciones solapadas— es la razón. La solución real no es revisar antes, sino hacer el efecto mismo idempotente, de modo que ni siquiera importe si dos ejecuciones lo intentan a la vez. Pero para apreciar por qué esa es la solución, primero tenías que ver por qué la obvia falla.

Qué cambió en n8n 2.0

n8n 2.0 —cuya línea 2.x se publicó a fines de 2025— trajo un canvas y un motor renovados. Para esta guía, el cambio más relevante es cómo se ejecuta el código.

En versiones anteriores, el nodo de código corría más cerca del proceso principal de n8n. En 2.0, el código corre aislado en un proceso separado llamado task runner. Este aislamiento tiene varias consecuencias, y la más importante para ti es un endurecimiento de lo que el nodo de código puede hacer. La documentación oficial de n8n es explícita en una restricción que esta guía respeta en todos sus ejemplos:

Desde el nodo de código no puedes acceder al sistema de archivos ni hacer peticiones HTTP.

Es decir: dentro de un nodo Code no vas a llamar a una API, ni leer un archivo, ni consultar un servicio externo. Para eso están los nodos dedicados —el HTTP Request para llamar APIs, el nodo de lectura/escritura de archivos para el disco—. Esto tiene una consecuencia directa en nuestro tema: todos los efectos externos de esta guía —crear un registro, cobrar, enviar un correo— los hace el nodo HTTP Request (o un nodo de integración específico), nunca el nodo Code. El nodo Code lo usaremos para pensar y transformar datos —por ejemplo, para construir una clave de idempotencia a partir del event_id—, no para ejecutar el efecto.

Un par de precisiones sobre el entorno del nodo Code que conviene tener presentes, porque acotan lo que puedes escribir:

• En n8n Cloud, el nodo Code solo tiene disponibles dos módulos: crypto (para cosas como calcular un hash) y moment (para fechas). Nada de instalar librerías externas.
• En self-hosted, puedes habilitar módulos adicionales por configuración, pero es un paso deliberado del administrador, no algo que esté por defecto.
• No cuentes, dentro del nodo Code, con hacer fetch, ni con require de cualquier cosa —más allá de lo permitido—, ni con acceder a variables de entorno del sistema como si nada. n8n 2.0 endureció justamente esos accesos.

No necesitas memorizar esta lista; la vas a tener a mano cuando escribas código en los módulos siguientes. Lo que sí quiero que te lleves es el principio: el nodo Code piensa, el nodo HTTP Request actúa. Esa separación no es un capricho de n8n; es la que te permite, más adelante, poner la protección de idempotencia en el lugar correcto.

Ejemplo trabajado: seguir un cobro duplicado en los datos de ejecución

Vamos a hacer, en la cabeza, lo que harías en la instancia real: rastrear un duplicado usando el modelo que acabas de aprender.

Supón que Cumbre reporta que a Luna Coffee le cobraron dos veces el pedido ORD-2041. Abres la lista de ejecuciones y filtras por ese pedido. Encuentras esto:

Ejecución #4471   09:12:03   ✔ éxito   pasó por: Webhook → ... → Create charge → Send Email
Ejecución #4472   09:12:05   ✔ éxito   pasó por: Webhook → ... → Create charge → Send Email

Qué esperar y cómo leerlo. Dos ejecuciones, con dos segundos de diferencia, las dos exitosas, las dos pasaron por Create charge. Ninguna falló. Ninguna tiene un error. Y sin embargo el cliente pagó dos veces. Esto te dice, sin ambigüedad, que no fue un fallo interno: fue un doble disparo. El webhook recibió el mismo pedido dos veces —09:12:03 y 09:12:05— y, fiel a su modelo, n8n creó dos ejecuciones independientes, cada una corrió el cobro, cada una cobró.

Si abres el nodo Webhook de cada ejecución y comparas los datos de entrada, vas a ver el mismo event_id: "evt_8f2a91c4" en las dos. Ahí está la prueba: dos ejecuciones, un solo evento. El proveedor reintentó, o alguien hizo doble clic, y como nadie estaba mirando el event_id para descartar la segunda, las dos pasaron.

Fíjate en lo que este ejercicio te dio: partiendo de "cobraron dos veces" y usando solo el modelo de ejecución —cada disparo una ejecución, los datos de cada ejecución— llegaste al diagnóstico exacto (doble disparo, mismo event_id) y a la forma de la solución (mirar el event_id para descartar el segundo). Eso es exactamente lo que vas a hacer de verdad en el Módulo 6, y es una de las promesas de la guía cumpliéndose.

Errores comunes

Creer que n8n recuerda que ya procesó algo (conceptual). Qué pasa: alguien asume que si el mismo pedido llega dos veces, n8n se dará cuenta y no lo procesará de nuevo. Luego aparece el duplicado. Por qué pasa: es una expectativa razonable —los humanos recordamos— pero n8n, por defecto, no tiene memoria entre ejecuciones: cada disparo es una ejecución nueva que arranca desde cero. Cómo detectarlo: si tu diseño depende de que "n8n no vuelva a procesar el mismo pedido" sin que tú hayas construido esa memoria, el diseño tiene un agujero. Cómo corregirlo: la memoria hay que dársela tú, con un lugar durable que recuerde qué pedidos ya se procesaron. Eso es el ledger del Módulo 4. Hasta que exista, asume que n8n procesará cada disparo como si fuera nuevo.

Activar Retry On Fail en un nodo que hace un efecto, sin protección (práctico). Qué pasa: alguien, buscando robustez, activa el reintento automático en Create charge o en un nodo que crea registros, y descubre que ante ciertos fallos el nodo cobra o crea dos veces. Por qué pasa: el reintento no distingue entre "la acción no se hizo" y "la acción se hizo pero no me confirmaron", así que reintenta en ambos casos. Cómo detectarlo: si tienes Retry On Fail activo en un nodo cuya acción es crear, cobrar, enviar o borrar, y ese efecto no es idempotente, tienes un duplicador potencial. Cómo corregirlo: reserva el reintento automático para lecturas y para efectos que ya hiciste idempotentes. Para un cobro sin proteger, primero vuélvelo idempotente (Módulo 2), después reintenta. El orden no es negociable.

Reintentar una ejecución completa para arreglar un fallo parcial (práctico). Qué pasa: una ejecución falló en el último paso —el correo— y alguien la reintenta completa para que el correo salga. El reintento vuelve a crear el registro y a cobrar. Por qué pasa: "reintentar" suena a "terminar lo que faltó", pero en realidad vuelve a ejecutar todos los nodos, incluidos los que ya se completaron. Cómo detectarlo: si reintentas ejecuciones completas de workflows con efectos no protegidos, cada reintento es un duplicado. Cómo corregirlo: hasta que los efectos sean idempotentes, no reintentes la ejecución completa de un fallo parcial; resuelve la parte que faltó de otra forma. Con efectos idempotentes (Módulo 2) y un ledger que recuerde qué se hizo (Módulo 4), el reintento vuelve a ser una herramienta segura.

Intentar hacer un efecto externo desde el nodo Code (práctico). Qué pasa: alguien escribe un fetch o un require de una librería HTTP dentro de un nodo Code para llamar a una API, y el nodo falla o se comporta raro, sobre todo en n8n 2.0. Por qué pasa: la documentación es explícita en que el nodo Code no puede hacer peticiones HTTP ni acceder al sistema de archivos, y 2.0 endureció ese aislamiento con los task runners. Cómo detectarlo: si tu nodo Code intenta llamar a un servicio externo, estás usando la herramienta equivocada. Cómo corregirlo: los efectos externos van en el nodo HTTP Request; el nodo Code se reserva para transformar datos y tomar decisiones. Esta separación, además de ser obligatoria, es la que te permite poner la idempotencia en el lugar correcto más adelante.

Ejercicios

Ejercicio 1 — Cuenta las ejecuciones. Para cada situación, di cuántas ejecuciones de order-triage crea n8n y por qué.

(a) Un pedido dispara el webhook una vez. (b) El proveedor, al no recibir confirmación, reenvía el mismo pedido tres veces en total. (c) Un pedido dispara el webhook, la ejecución falla en Send Email, y tú la reintentas completa una vez. (d) Tres pedidos distintos llegan casi al mismo tiempo.

Ver solución

(a) Una ejecución. Un disparo, una ejecución. El caso normal.

(b) Tres ejecuciones. Cada reenvío es un disparo, y cada disparo crea una ejecución independiente, aunque el pedido sea el mismo. Las tres corren los seis nodos; sin protección, las tres cobran.

(c) Dos ejecuciones. La original (que falló) y el reintento (que corre de nuevo). El reintento vuelve a ejecutar los nodos que la original ya había completado, así que vuelve a crear el registro y a cobrar.

(d) Tres ejecuciones, una por pedido. Aquí no hay duplicado —son tres pedidos distintos— pero corren en paralelo, lo cual será relevante en el Módulo 5 cuando hablemos de coordinación y de orden.

Por qué funciona: fíjate que en (b) y (c) hay más ejecuciones que pedidos de negocio, y ese exceso es exactamente donde nacen los duplicados. La unidad de n8n es el disparo; la unidad del negocio es el pedido; el desajuste entre las dos es el problema.

Ejercicio 2 — Diagnostica con los datos de ejecución. Un cliente reporta que recibió tres correos de confirmación idénticos por un solo pedido. Abres la lista de ejecuciones y encuentras cuatro ejecuciones de ese pedido: tres exitosas y una fallida en Create charge. Con solo el modelo de esta lección, ¿qué probablemente pasó y qué revisarías para confirmarlo?

Ver solución

Lo más probable: el pedido llegó al webhook cuatro veces (cuatro disparos → cuatro ejecuciones). Tres de esas ejecuciones completaron todo el flujo, incluido Send Email, y por eso salieron tres correos. La cuarta falló en Create charge —quizá un parpadeo de la pasarela— y por eso no mandó su correo (nunca llegó a Send Email).

Para confirmarlo revisaría dos cosas. Primera: el event_id en el nodo Webhook de las cuatro ejecuciones. Si es el mismo en las cuatro, confirma que fue un pedido reenviado cuatro veces, no cuatro pedidos distintos. Segunda: en las tres ejecuciones exitosas, revisaría el nodo Create charge para ver si el cliente además fue cobrado tres veces —lo cual convertiría un problema molesto (tres correos) en uno grave (tres cobros)—.

Por qué funciona: partiendo solo de "tres correos" y usando el modelo —cada disparo una ejecución, los datos de cada ejecución— reconstruiste la historia completa y supiste exactamente qué campo mirar para confirmarla. Esa es la habilidad de investigación que el dueño del sistema usa todos los días.

Ejercicio 3 — Clasifica el riesgo del reintento. Para cada nodo de order-triage, di si activarle Retry On Fail (reintento automático al fallar) sería seguro o peligroso tal como está el workflow hoy, sin ninguna protección de idempotencia, y por qué.

(a) Get customer (consulta la ficha del cliente en el CRM). (b) Create CRM order (crea el registro del pedido). (c) Create charge (cobra). (d) Send Email (manda el correo).

Ver solución

(a) Get customer: seguro. Es una lectura. Consultar la ficha del cliente dos, tres o diez veces da siempre lo mismo y no cambia nada en el CRM. Reintentar una lectura nunca hace daño. Este es el caso donde Retry On Fail brilla.

(b) Create CRM order: peligroso. Es un efecto de creación sin protección. Si la creación se hizo pero la confirmación se perdió, el reintento crea un segundo registro. Duplicado.

(c) Create charge: peligroso, y es el más grave. Efecto de cobro sin protección. Un reintento puede cobrar dos veces, y un cobro duplicado es de los daños menos reversibles y más costosos.

(d) Send Email: peligroso, pero menos grave. Efecto de envío. Un reintento puede mandar un segundo correo. Molesto, rara vez costoso, pero sigue siendo un duplicado.

Por qué funciona: fíjate en el patrón, que es el de la lección 7. El único nodo seguro de reintentar es el único que es una lectura. Todos los efectos son peligrosos de reintentar mientras no estén protegidos. Reintentar no es bueno ni malo en sí mismo; su seguridad depende por completo de si lo que reintenta es una lectura o un efecto protegido.

Resumen y siguiente paso

En esta lección abriste el motor de n8n 2.0. Una ejecución es una corrida completa del workflow disparada por un evento, y el hecho que sostiene toda la guía es que cada disparo crea una ejecución independiente: n8n piensa en disparos, no en pedidos de negocio, y por eso no recuerda por sí solo que ya procesó algo. Dentro de una ejecución, los items fluyen de nodo en nodo, y cada nodo ejecuta su acción sin preguntar si ya la hizo antes. Los datos de ejecución —el registro de qué pasó en cada corrida— son tu ventana para investigar un incidente y, más adelante, para reproducirlo.

El corazón técnico fue el reintento, que existe en dos formas: el de un nodo (Retry On Fail, con su número de intentos y su espera) y el de una ejecución completa (con la opción de usar el workflow original o el actual). Las dos comparten lo esencial: vuelven a ejecutar acciones, y por eso un reintento sobre un efecto no protegido puede duplicar —el nodo no distingue entre "no se hizo" y "se hizo pero no me enteré"—. Y viste el cambio de n8n 2.0 que más te afecta: el nodo Code corre aislado en un task runner, no puede hacer peticiones HTTP ni tocar el sistema de archivos, así que los efectos externos van siempre por el nodo HTTP Request. El nodo Code piensa; el nodo HTTP Request actúa.

Antes de avanzar deberías poder: explicar por qué dos disparos del mismo pedido crean dos ejecuciones que ambas cobran; describir por qué un reintento automático de un cobro puede duplicar aunque el reintento sea bienintencionado; y decir dónde deben vivir los efectos externos y por qué no en el nodo Code.

Ya sabes que cada disparo es una ejecución y que reintentar re-ejecuta. Lo que falta es la pregunta que quedó suelta: ¿por qué los disparadores mismos entregan el mismo evento dos veces? No es un accidente ni un bug del proveedor. La lección 5 te muestra que casi todo disparador ofrece una garantía llamada "al menos una vez" —nunca "exactamente una vez"— y que esa garantía es la razón de fondo por la que el problema del duplicado no es una excepción rara, sino la regla con la que hay que diseñar.

Recursos

• Executions — n8n Docs — la lista de ejecuciones: dónde ves el estado, los nodos y los datos de cada corrida. La herramienta central para investigar duplicados.
• Retry an execution — n8n Docs — cómo reintentar ejecuciones en n8n; conviene confirmar en esta página las opciones exactas que ofrece tu versión (workflow original vs actual).
• Code node — n8n Docs — la ficha oficial del nodo Code, con la restricción explícita de que no puede acceder al sistema de archivos ni hacer peticiones HTTP, y las notas sobre módulos disponibles.
• Task runners — n8n Docs — la explicación del aislamiento de código que introdujo n8n 2.0; útil para entender por qué el nodo Code está más restringido que antes.
• Release notes 2.x — n8n Docs — el historial de la versión 2; verifica aquí la versión que corres frente al modelo que describe esta lección.