6. Re-ejecutar un solo nodo y editar entradas

Descripción

Al terminar esta lección vas a poder cerrar el ciclo de depuración más corto que existe en n8n: cambias una expresión, ejecutas solo ese nodo, y ves el resultado en un segundo, sin recorrer el workflow entero y sin tocar nada de lo que viene después. Vas a conocer la ejecución parcial con su nombre literal —Execute step—, qué hace exactamente (ejecuta el nodo que elegiste y los nodos anteriores que hagan falta para darle entrada), cómo se combina con los datos fijados de la lección 5 para volverse instantánea, y una restricción que sorprende: n8n te pide un trigger conectado incluso para probar un solo nodo.

Esto importa porque la velocidad del ciclo de depuración decide cuántas hipótesis puedes probar antes de cansarte. Si cada prueba corre quince nodos y tarda diez segundos, probar diez ideas son cien segundos y diez oportunidades de que algún nodo con efectos haga algo que no querías. Si cada prueba corre un solo nodo y tarda medio segundo, probar diez ideas son cinco segundos y cero efectos colaterales. La diferencia no es de comodidad: es la diferencia entre explorar con soltura y racionar cada intento.

Conexión con el módulo: esta es la tercera y última herramienta de experimento, la más quirúrgica de las tres. La lección 3 repetía la ejecución entera; la lección 5 congelaba la entrada; esta ejecuta un único nodo. Las tres se combinan en un solo flujo de trabajo que vas a usar constantemente: fijas la entrada (lección 5) y ejecutas solo el nodo que estás arreglando (esta lección), con lo cual el ciclo cambiar-probar-mirar baja a segundos y no toca ni el sistema externo ni los nodos posteriores. Después de esta lección tienes el kit completo de herramientas; la 7 y la 8 son conocimiento y práctica.

El tornillo, no el motor entero

Un mecánico ajusta el ralentí de un motor. El ajuste es un tornillo que abre o cierra un paso de aire, y encontrar el punto exacto es prueba y error: aflojar un cuarto de vuelta, escuchar, aflojar otro poco, escuchar.

Ningún mecánico del mundo apaga el motor, lo desarma, cambia el tornillo, lo vuelve a armar y lo enciende para oír cómo quedó. Sería absurdo: cada iteración tomaría una hora y no podría comparar, porque entre una prueba y otra desarmó y armó medio motor.

Lo que hace es dejar el motor encendido y estable, y tocar solo el tornillo, escuchando el efecto inmediato de cada ajuste. El resto del motor no cambia. La única variable es el tornillo.

Volver a ejecutar un solo nodo es tocar el tornillo con el motor encendido. El workflow entero se queda como está —las salidas de los nodos anteriores, ya calculadas; los nodos posteriores, sin tocar— y tú ajustas un nodo y oyes el resultado. Cambias la expresión, ejecutas ese nodo, miras. Un cuarto de vuelta cada vez.

Y la conexión con la lección anterior es exacta: los datos fijados son lo que mantiene el motor encendido y estable. Si la entrada del nodo está fija, cada vez que ejecutas el nodo entra exactamente lo mismo, y todo lo que cambie en la salida lo cambiaste tú. Sin esa estabilidad, estarías ajustando el tornillo mientras alguien acelera el motor a tus espaldas.

Qué es la ejecución parcial

Hasta ahora, "ejecutar" ha significado correr el workflow completo, desde el trigger hasta el final. La ejecución parcial es correr solo una parte, y es un tipo de ejecución que la documentación reconoce formalmente.

La definición oficial: una ejecución parcial es un subtipo de la ejecución manual que corre solo un subconjunto de los nodos del workflow. Sirve, textualmente, para probar y depurar partes concretas de tu workflow sin correr el workflow entero.

Cómo se dispara, con el nombre literal: seleccionas un nodo, abres su vista de detalle, y eliges Execute step.

Qué hace exactamente —y esto es lo que hay que entender bien: Execute step ejecuta el nodo que elegiste y cualquier nodo anterior que haga falta para llenar su entrada.

Esa segunda mitad es la que sorprende a mucha gente, así que vale la pena desarmarla.

   Webhook ──► Set ──► Code ──► HTTP Request ──► Postgres
      1        2       3 ⬅ pulsas Execute step aquí

   n8n necesita que el nodo 3 tenga una entrada válida.
   Su entrada la produce el nodo 2, cuya entrada produce el 1.

   Resultado de Execute step en el nodo 3:
   - Si 1 y 2 YA tienen datos (de una corrida previa o fijados):
        n8n reusa esos datos y ejecuta SOLO el nodo 3.   ← el caso rápido
   - Si 1 y 2 NO tienen datos:
        n8n ejecuta 1, luego 2, luego 3, para poder darle
        entrada al 3.                                    ← corre lo necesario

La regla, en una frase: Execute step ejecuta el nodo objetivo, y de los anteriores solo corre los que hagan falta para darle una entrada. Si los anteriores ya tienen su salida disponible —porque los corriste antes en esta sesión, o porque están fijados—, no los vuelve a correr: aprovecha lo que ya está.

Por eso los datos fijados de la lección 5 son el multiplicador de esta lección. Con la entrada del nodo fijada, Execute step no tiene nada anterior que correr: ejecuta tu nodo y ya. Ese es el ciclo de medio segundo.

Por qué esto es más seguro, además de más rápido

La velocidad es lo obvio. Hay un segundo beneficio, menos visible y a veces más importante: ejecutar un solo nodo no corre los nodos posteriores.

Recuerda el andamio de la lección 3: cuando depurabas la ejecución entera, tenías que desactivar o fijar los nodos con efectos —Create order in ERP, los Postgres— para que tus cuarenta pruebas no crearan cuarenta pedidos. Con la ejecución parcial, ese problema desaparece por diseño: si ejecutas solo el nodo Validate and normalize order, el nodo Create order in ERP que viene después no corre, punto. No hay que desactivarlo porque nunca se le pide que se ejecute.

   Webhook ──► Validate ──► Create order in ERP ──► Log to ops
                  ▲                  │                    │
            Execute step         NO corre             NO corre
            corre esto           (está después)       (está después)

Esto convierte la ejecución parcial en la herramienta preferida para depurar el nodo que precede a algo con efectos. Toda tu iteración ocurre antes de la frontera peligrosa, sin cruzarla nunca. Es más limpio que fijar los nodos de efectos, porque no tienes que fijar nada ni acordarte de quitarlo después: simplemente no ejecutas esa parte del workflow.

La combinación completa, que es como vas a trabajar de verdad:

Fija la entrada del nodo (lección 5) + Execute step sobre el nodo (esta lección) = iteración instantánea, sin llamar al sistema externo de entrada, y sin tocar los nodos de efectos de salida.

Aislaste el nodo por los dos lados. Entra un dato fijo; sale a ninguna parte. El nodo está en una mesa de trabajo.

La restricción que sorprende: necesitas un trigger

Aquí hay un detalle que confunde a mucha gente y conviene saberlo antes de toparse con él.

La documentación lo dice: si intentas hacer una ejecución parcial sin un trigger conectado al workflow, aparece un error. La razón es que las ejecuciones manuales —y la parcial es una manual— intentan imitar a las de producción en lo posible, y una ejecución de producción siempre empieza con un trigger que describe cuándo debe correr la lógica. Sin trigger, n8n no sabe cómo empezar, aunque tú solo quieras probar el nodo tres.

La solución es la que sugiere la propia documentación: conecta un trigger al workflow con el nodo que quieres ejecutar. Puede ser el trigger real del workflow, o —muy útil al construir o depurar aislado— un Manual Trigger, ese que existe precisamente para dar un punto de arranque a las pruebas.

Qué esperar. Si armas un fragmento suelto de nodos para experimentar —un patrón común cuando reproduces un caso raro— y pulsas Execute step sin haber conectado nada que dispare, vas a ver ese error en vez del resultado. No es un fallo de tu nodo: es que falta el punto de partida. Conecta un Manual Trigger delante y vuelve a probar. Verifica en tu panel el texto exacto del error y el nombre del trigger disponible en tu versión.

Editar la entrada de un nodo

La otra mitad del título de esta lección es "editar entradas", y es donde la ejecución parcial se junta con la técnica de edición de la lección 5 para producir la iteración más fina posible.

La idea: no solo puedes ejecutar un nodo aislado, sino ejecutarlo contra una entrada que tú modificaste a mano para probar una variante. Y esto se apoya en algo que ya sabes hacer.

El camino, usando los datos fijados de la lección 5. La entrada de un nodo es la salida del nodo anterior. Si fijas la salida del nodo anterior y la editas —botón Edit en vista JSON, Save—, cambiaste la entrada del nodo que estás depurando. Ahora pulsas Execute step sobre tu nodo y lo pruebas contra la variante que fabricaste.

Para el caso del módulo, esto es directo. Estás arreglando Validate and normalize order. Fijas la salida del Webhook que le da entrada, y la editas para probar tres variantes seguidas:

1. Con shipping completo → Execute step → confirmas que el pedido normal funciona.
2. Editas: quitas shipping, añades fulfillment: pickup → Execute step → confirmas que la rama de recogida funciona.
3. Editas: quitas shipping y fulfillment → Execute step → descubres qué hace tu código con el caso que no previste.

Tres pruebas, tres ediciones, tres ejecuciones de un solo nodo. Segundos en total. Y el nodo Create order in ERP no se enteró de nada, porque nunca corrió.

El atajo de copiar y pegar. La lección 5 mencionó que puedes copiar items de una ejecución anterior y pegarlos en los datos fijados. Para depurar casos borde, esto es oro: tienes en dead_letter el JSON de los catorce pedidos que fallaron; copias uno, lo pegas como entrada fijada, y pruebas tu arreglo contra el caso real exacto sin reconstruir nada. Es reproducir el incidente con copiar y pegar.

Ejemplo trabajado: afinar la expresión del carrier, un nodo a la vez

Vamos con un caso que muestra el ciclo corto en acción, y que además introduce un matiz que no habíamos tocado: a veces el bug no está en un nodo Code, sino en una expresión de un nodo normal.

La situación. Después de arreglar el nodo Code de la lección 4, el pedido de recogida ya no revienta: sale con carrier: "PICKUP". Pero ahora el nodo siguiente, un Set llamado Build ERP payload, arma el campo que el erp espera con esta expresión:

{{ $json.carrier }}-{{ $json.shipping.city }}

Y para el pedido de recogida, ese Set produce PICKUP-undefined, porque shipping.city no existe. No revienta —una expresión con undefined produce texto, no un error—, pero manda basura al erp. Es un fallo silencioso, y lo detectaste comparando la salida contra un pedido normal.

Sin ejecución parcial, cada intento de arreglar la expresión sería: cambiar la expresión, ejecutar el workflow entero, esperar a que corra el Webhook, el Code, el Set, y —si no lo desactivaste— el nodo que llama al erp. Diez segundos y un riesgo por vuelta.

Con ejecución parcial, el ciclo es otro:

Paso 1 — Fija la entrada del Set. La salida del nodo Code anterior ya la tienes de una corrida; la fijas. Ahora la entrada de Build ERP payload es constante: el pedido de recogida normalizado, con carrier: "PICKUP" y sin shipping.

Paso 2 — Cambia la expresión y ejecuta solo el Set. Pruebas una primera idea:

{{ $json.carrier }}-{{ $json.ship_city }}

Pulsas Execute step sobre el Set. Miras la salida: PICKUP-PUE-CENTRO-02. Usaste ship_city, el campo que el nodo Code ya normalizó para cubrir los dos casos, en vez de shipping.city, que solo existe en los pedidos con envío. Funciona.

Paso 3 — Verifica el otro caso. Editas la entrada fijada para volver a un pedido normal con shipping, Execute step, y confirmas: ANDES-EXPRESS-Puebla. Los dos casos pasan.

Qué esperar. Cada vuelta de este ciclo son uno o dos segundos: solo corre el Set. Comparado con ejecutar el workflow entero, no es "un poco más rápido": es un orden de magnitud, y esa diferencia es la que te deja probar la variante que se te ocurre a los diez minutos sin la fricción que te haría no probarla. Y fíjate en el detalle de método: probaste el arreglo contra los dos casos, el de recogida y el normal, porque un arreglo que solo se verifica contra el caso raro es como el que arregla el caso raro y rompe el normal.

El matiz sobre expresiones. Este ejemplo muestra que el ciclo corto no es solo para nodos Code. Una expresión mal escrita en un Set, un IF, un Filter o un HTTP Request es una fuente de bugs tan común como el código, y la ejecución parcial la depura igual de bien: cambias la expresión, ejecutas ese nodo, miras. Cómo escribir la expresión correcta —el manejo de undefined en expresiones, los operadores seguros— pertenece a la construcción de workflows; aquí lo que importa es el ciclo que te deja probarla rápido.

Propagar el arreglo hacia adelante, un nodo a la vez

Hay un uso de la ejecución parcial que la gente descubre tarde y que vale la pena adelantar, porque resuelve una pregunta que aparece siempre después de arreglar un nodo: "vale, este nodo ya produce lo correcto; ¿pero el siguiente sabe qué hacer con eso?".

El caso concreto en Terra Market. Arreglaste Validate and normalize order para que un pedido de recogida salga con carrier: "PICKUP". El nodo produce ahora un valor que nunca antes había existido: hasta hoy, carrier siempre era ANDES-EXPRESS o similar, jamás PICKUP. Y esa es justo la clase de novedad que rompe el nodo siguiente, porque el nodo siguiente se escribió cuando PICKUP no era una posibilidad.

Aquí la ejecución parcial se usa como una sonda que avanza. En vez de correr el workflow entero y ver dónde revienta, empujas tu dato arreglado un nodo a la vez y observas cada paso:

1. Execute step sobre Validate and normalize order. Confirmas: sale carrier: "PICKUP". Bien.
2. Execute step sobre el nodo siguiente, Build ERP payload. Ahora su entrada es tu dato arreglado —n8n reusa la salida fresca del nodo 1—. Miras qué hace con PICKUP. Aquí aparece el PICKUP-undefined del ejemplo anterior: el nodo siguiente no sabía qué hacer con el caso nuevo.
3. Arreglas ese nodo, Execute step, confirmas. Avanzas al siguiente.
4. Execute step sobre Create order in ERP... y aquí paras, porque ese tiene efectos. Este nodo no lo sondeas ejecutándolo: lo revisas mirando qué payload le llegaría, con el nodo anterior ya arreglado y su salida a la vista.

Qué esperar. Espera que arreglar un nodo destape trabajo en el siguiente más veces de las que crees. Un valor nuevo que un nodo empieza a producir es un cambio de contrato hacia adelante, igual que el shipping ausente fue un cambio de contrato hacia atrás. La sonda que avanza te deja encontrar esos efectos en cadena de uno en uno, en el editor, en vez de descubrirlos todos juntos y en producción. Es la diferencia entre caminar un puente tablón por tablón probando cada uno, y cruzarlo corriendo con los ojos cerrados.

Y fíjate en el límite que reaparece: la sonda avanza hasta el primer nodo con efectos y ahí se detiene. Ese nodo no se prueba ejecutándolo —crearía un pedido—, se prueba inspeccionando la entrada que le llegaría. La verificación de que de verdad funciona de punta a punta es la ejecución completa contra un entorno de prueba, que es la prueba final de la lección 3 y del proyecto de la lección 8.

Los nodos "sucios" y por qué te conviene mirarlos

La lección 5 introdujo los nodos sucios (dirty) de n8n 2.x: los que muestran un triángulo amarillo porque su salida guardada ya no es confiable. Aquí esa función se vuelve una guía directa de qué re-ejecutar.

Cuando cambias los parámetros de un nodo —una expresión, el código—, ese nodo y los que dependen de él se marcan sucios. El triángulo amarillo te está diciendo: "lo que ves aquí es viejo; si ejecutaras ahora, saldría otra cosa". Y ejecutar el nodo —Execute step— limpia su estado sucio y actualiza su salida.

Para el ciclo de depuración, esto es una brújula: los nodos amarillos son exactamente los que tienes que re-ejecutar para ver el efecto de tu cambio. Si cambiaste el nodo 3 y ves amarillos el 3, el 4 y el 5, sabes que tu cambio afecta a esos tres, y que los datos que muestran ahora mismo no reflejan tu edición. No tienes que adivinar qué re-correr: n8n te lo pinta.

Verifica en tu panel. El color, el icono y el comportamiento exacto de los nodos sucios pueden variar entre versiones de la línea 2.x. Lo que no cambia es el concepto: n8n distingue entre "esta salida es fresca" y "esta salida quedó vieja tras tu cambio", y esa distinción te dice qué ejecutar.

Cuándo el ciclo corto no basta

Como toda herramienta, la ejecución parcial tiene su frontera, y conocerla evita usarla donde no rinde.

Cuando el bug depende de la interacción entre nodos. Si el problema aparece solo cuando el nodo 3 recibe la salida real del nodo 2 —no una fijada—, aislarlos te lo esconde. En ese caso quieres correr los dos juntos, o el workflow entero, para reproducir la interacción. La ejecución parcial es para depurar un nodo; cuando el bug vive entre nodos, sube un nivel.

Cuando el bug depende del estado acumulado. Un workflow con un bucle que arrastra un acumulador, o que usa datos estáticos entre ejecuciones, puede comportarse distinto en una ejecución parcial que en una completa, porque el estado no se construyó igual. Ahí la reproducción fiel exige la ejecución completa de la lección 3.

Cuando ya arreglaste y quieres la prueba final. El ciclo corto es para iterar rápido mientras buscas el arreglo. Una vez que crees haberlo encontrado, la verificación final se hace corriendo el workflow completo —con la entrada fijada, y con los nodos de efectos desactivados o apuntando a un entorno de prueba—, porque quieres confirmar que el arreglo funciona en el contexto real del flujo, no solo en la mesa de trabajo. Ajustas el tornillo con el ciclo corto; confirmas el ralentí con el motor entero encendido.

Errores comunes

Ejecutar el workflow entero para probar un cambio de un nodo (práctico). Qué pasa: se cambia una expresión en el nodo tres y se ejecuta el workflow completo para verla, corriendo doce nodos de más cada vez, algunos con efectos. La depuración se vuelve lenta y arriesgada, y esa lentitud desanima a probar variantes. Por qué pasa: ejecutar todo es el botón grande y conocido; Execute step está en la vista de detalle del nodo y hay que descubrirlo. Cómo detectarlo: si estás iterando sobre un nodo y cada vuelta tarda más de un par de segundos, casi seguro estás corriendo de más. Cómo corregirlo: fija la entrada del nodo y usa Execute step. El ciclo baja de diez segundos a uno, y los nodos posteriores dejan de correr.

Olvidar que Execute step puede correr los nodos anteriores (práctico). Qué pasa: se pulsa Execute step sobre un nodo esperando que corra solo ese, y n8n ejecuta también tres nodos anteriores —uno de los cuales llama a una API— porque el nodo objetivo no tenía entrada disponible. Se dispara una llamada que no se esperaba. Por qué pasa: la mitad "y los nodos anteriores que hagan falta" de la definición es fácil de pasar por alto. Cómo detectarlo: si Execute step tarda más de lo que un solo nodo debería, o si ves actividad en nodos anteriores, es que los está corriendo. Cómo corregirlo: fija la salida de los nodos anteriores para que Execute step tenga la entrada lista y no necesite correr nada más. Con la entrada fijada, ejecuta de verdad solo tu nodo.

Intentar la ejecución parcial sin trigger (práctico). Qué pasa: se arma un fragmento de nodos sueltos para experimentar, se pulsa Execute step, y aparece un error en vez del resultado. Se pierde tiempo buscando el fallo en el nodo, que está bien. Por qué pasa: n8n exige un trigger conectado para cualquier ejecución, incluso parcial, porque imita a producción. Cómo detectarlo: el error habla de la falta de un trigger o de un punto de arranque, no de tu nodo. Cómo corregirlo: conecta un Manual Trigger —o el trigger real— delante del fragmento que quieres probar. Es el punto de partida que n8n necesita para empezar.

Confiar en una salida vieja de un nodo sucio (práctico). Qué pasa: se cambia una expresión, se mira la salida del nodo sin re-ejecutarlo, y se saca una conclusión de datos que corresponden a la versión anterior del nodo. Se cree que el cambio no funcionó —o que funcionó— basándose en una salida obsoleta. Por qué pasa: la salida sigue mostrándose después de editar, y es fácil olvidar que ya no corresponde a lo que hay en el nodo. Cómo detectarlo: el triángulo amarillo del nodo sucio te avisa de que su salida quedó vieja. Cómo corregirlo: re-ejecuta el nodo —Execute step— después de cada cambio, y lee la salida solo cuando el nodo esté "limpio". Nunca saques conclusiones de un nodo amarillo.

Ejercicios

Ejercicio 1 — ¿Qué corre exactamente? Tienes este workflow con la salida del Webhook fijada. Para cada acción, di qué nodos se ejecutan.

Webhook 📌 ──► Set "Normalize" ──► Code "Enrich" ──► HTTP "Create in ERP" ──► Postgres "Log"

(a) Pulsas Execute step sobre Code "Enrich", y Set "Normalize" ya tiene salida de una corrida anterior. (b) Pulsas Execute step sobre Code "Enrich", y Set "Normalize" NO tiene salida. (c) Pulsas Execute step sobre Set "Normalize". (d) Ejecutas el workflow completo.

Ver solución

(a) Solo corre Code "Enrich". Su entrada la produce Set "Normalize", que ya tiene salida disponible, así que n8n la reusa y no lo vuelve a correr. El Webhook está fijado, tampoco corre. Y los nodos posteriores —HTTP y Postgres— no corren porque están después del objetivo. Este es el caso ideal: un solo nodo, sin efectos.

(b) Corren Set "Normalize" y Code "Enrich", en ese orden. Como Enrich necesita una entrada y Normalize no la tenía lista, n8n ejecuta primero Normalize para producirla, y luego Enrich. El Webhook sigue sin correr porque está fijado y entrega su dato directamente. Los posteriores, tampoco. Nota que aquí Execute step corrió dos nodos, no uno: es la mitad "y los anteriores que hagan falta" en acción.

(c) Solo corre Set "Normalize". Su entrada la da el Webhook, que está fijado y entrega su dato sin ejecutarse. Nada más corre.

(d) Corren los cinco nodos, salvo que el Webhook, por estar fijado, entrega su dato fijado en vez de esperar un webhook real. Es decir: el Webhook "corre" entregando la foto, y Set, Code, HTTP y Postgres corren de verdad —incluido el que crea el pedido en el erp y el que escribe en la base—. Este es el caso que quieres para la verificación final, y el que exige tener desactivados o apuntados a prueba los nodos de efectos.

Por qué funciona: los cuatro casos muestran la regla completa. Execute step corre el objetivo más los anteriores que no tengan entrada lista, nunca los posteriores. Y fijar los nodos anteriores es lo que convierte "corre el objetivo y sus anteriores" en "corre solo el objetivo".

Ejercicio 2 — Diseña el ciclo. Estás arreglando el nodo Build ERP payload (un Set con una expresión) que produce basura para los pedidos de recogida. Describe el ciclo de trabajo más rápido y seguro para iterar sobre la expresión, usando lo de las lecciones 5 y 6, y di qué nodo de efectos NO se toca en ningún momento.

Ver solución

El ciclo:

1. Consigue la entrada del Set. Es la salida del nodo Code anterior. Corre el workflow una vez, o trae al editor una ejecución con el pedido de recogida, para tenerla.
2. Fija la salida del Code. Con Pin data. Ahora la entrada de Build ERP payload es constante: el pedido de recogida normalizado.
3. Itera: cambia la expresión del Set → Execute step sobre el Set → mira la salida. Repite hasta que la expresión produzca lo correcto. Cada vuelta es un segundo porque solo corre el Set (su entrada está fijada, no hay anteriores que correr).
4. Verifica el otro caso: edita la entrada fijada para volver a un pedido normal con shipping → Execute step → confirma que ese también sale bien.
5. Limpia: quita la fijación del Code antes de publicar.

El nodo de efectos que NO se toca en ningún momento: Create order in ERP. Está después de Build ERP payload, así que Execute step sobre el Set nunca lo ejecuta. No hay que desactivarlo ni fijarlo: la ejecución parcial lo deja fuera por diseño. Esa es la ventaja de depurar un nodo que precede a los efectos con la herramienta de un solo nodo.

Por qué funciona: el ciclo combina las dos últimas lecciones en su forma más pura —entrada fija por un lado, ejecución de un solo nodo por el otro— y el resultado es un nodo completamente aislado, rápido de probar y sin riesgo de tocar producción. Es como vas a depurar la mayoría de los nodos en tu trabajo real.

Ejercicio 3 — Elige la herramienta. Para cada situación, di si usarías ejecución parcial (un nodo), replay de la ejecución entera (lección 3), o la ejecución completa con datos fijados, y por qué.

(a) Afinar una expresión en un Set, probando cinco variantes seguidas. (b) Confirmar que el arreglo terminado funciona en el flujo completo antes de publicar. (c) Un bug que solo aparece cuando el nodo Code recibe la salida real —no fijada— de una llamada al erp que a veces devuelve un campo extra. (d) Reproducir por primera vez un incidente de anoche cuya ejecución todavía existe.

Ver solución

(a) Ejecución parcial sobre el Set, con su entrada fijada. Cinco variantes seguidas es exactamente el caso del ciclo corto: cada prueba es un segundo y los nodos posteriores no se tocan. Usar la ejecución completa aquí sería correr doce nodos de más cinco veces.

(b) Ejecución completa con datos fijados, y con los nodos de efectos desactivados o apuntando a un entorno de prueba. La verificación final quiere el contexto real del flujo entero, no un nodo aislado: quieres ver que la salida del nodo arreglado encaja de verdad con lo que espera el siguiente. El ciclo corto ya hizo su trabajo; ahora toca la prueba de integración.

(c) Replay de la ejecución entera (lección 3), o al menos correr el Code con la salida real del erp, sin fijar. El bug vive en la interacción: depende de qué devuelve de verdad la API. Si fijas la salida del erp con un dato "normal", escondes justo el caso del campo extra. Aquí aislar hace daño; necesitas la interacción real. Es la frontera de esta lección.

(d) Replay de la ejecución entera con Debug in editor, que trae los datos y los fija en el primer nodo. Para la primera reproducción quieres el incidente completo, tal como ocurrió, para ver dónde se detuvo y qué pasó en todo el flujo. Una vez reproducido y localizado el nodo culpable, bajas al ciclo corto de esta lección para iterar sobre el arreglo.

Por qué funciona: las tres herramientas forman una escalera de lo grueso a lo fino —ejecución entera para reproducir y para la prueba final, un solo nodo para iterar—, y se usan en ese orden dentro de un mismo incidente: reproduces con la grande, arreglas con la chica, verificas con la grande otra vez. El caso (c) recuerda que a veces hay que subir de nuevo a la grande porque el bug no cabe en un nodo.

Resumen y siguiente paso

En esta lección cerraste el kit de herramientas del módulo con el ciclo de depuración más corto: volver a ejecutar un solo nodo. Viste la ejecución parcial con su nombre literal —Execute step— y su comportamiento exacto: corre el nodo que elegiste y solo los nodos anteriores que hagan falta para darle entrada, nunca los posteriores. Entendiste por qué eso es a la vez más rápido (un nodo en vez de quince) y más seguro (los nodos de efectos que vienen después no se ejecutan, sin tener que desactivarlos). Aprendiste que se combina con los datos fijados de la lección 5 en el flujo que vas a usar todo el tiempo —entrada fijada + Execute step = iteración instantánea y aislada—, y con la edición de la entrada para probar variantes a mano, incluido el atajo de pegar un caso real desde dead_letter. Conociste la restricción que sorprende —n8n exige un trigger conectado incluso para una ejecución parcial, y se resuelve con un Manual Trigger— y viste que los nodos sucios de n8n 2.x son la brújula de qué re-ejecutar. Y quedó marcada la frontera: el ciclo corto es para iterar sobre un nodo; cuando el bug vive entre nodos o depende del estado acumulado, se vuelve a la ejecución entera, que también es la de la verificación final.

Antes de avanzar deberías poder: decir qué corre y qué no corre Execute step sobre un nodo; explicar por qué necesitas un trigger para probar un solo nodo; y describir el ciclo de dos piezas que aísla un nodo por completo.

Con esto tienes las cinco herramientas del oficio: leer la ejecución (2), repetirla (3), trazar variables dentro del nodo (4), fijar datos (5) y ejecutar un solo nodo (6). Lo que te falta no es una herramienta más: es experiencia. Un operador con oficio no recorre el método de las cuatro preguntas desde cero en cada incidente, porque reconoce el patrón de un vistazo: "un undefined que aparece solo en algunos items huele a campo opcional", "un total en cero huele a número que llegó como texto". La lección 7 es ese catálogo —los siete patrones de fallo que explican la mayoría de los incidentes de producción, cada uno con su síntoma, su causa y el camino más corto a su diagnóstico—. Es la memoria del oficio, para que no tengas que aprender cada patrón rompiéndote contra él.

Recursos

• Types of executions — n8n Docs — la definición de la ejecución parcial, cómo se dispara con Execute step, y la nota de que ejecuta el nodo objetivo más los anteriores necesarios para su entrada.
• Understand executions — n8n Docs — el marco general que incluye por qué una ejecución manual (y por tanto la parcial) necesita un trigger conectado para poder correr.
• Understand dirty nodes — n8n Docs — cómo n8n 2.x marca los nodos cuya salida quedó vieja tras un cambio, la brújula de qué re-ejecutar durante la depuración.
• Pin and mock data — n8n Docs — la pieza de la lección 5 que hace instantáneo el ciclo corto: con la entrada fijada, Execute step no tiene anteriores que correr.