Hola a todos - me encuentro con un problema persistente en el comportamiento de doble salida del nodo Execute Workflow cuando está configurado “On Error: Continue (using error output)”. Espero que alguien se haya topado con esto y haya encontrado un patrón limpio.
Configuración
-
Un flujo de trabajo padre llama a un subflujo mediante Execute Workflow.
-
Configuración del nodo Execute Workflow:
-
Modo: Ejecutar una vez por cada elemento
-
Esperar a que se complete el subflujo: ACTIVADO
-
On Error: Continue (using error output)
-
-
El nodo terminal del subflujo es una actualización de Google Sheets.
-
El padre tiene dos ramas descendentes: ruta de éxito (limpieza + alerta Telegram + página de finalización de formulario) y ruta de error (alerta de error Telegram + página de finalización de error).
El comportamiento que estoy viendo
Tengo dos modos de fallo dependiendo de la configuración Always Output Data en el nodo Execute Workflow del padre:
Caso A - Always Output Data DESACTIVADO en el nodo Execute Workflow del padre:
-
Cuando el subflujo tiene éxito: el nodo terminal (Sheets update) emite 1 elemento con los datos de fila completos. La pestaña Success Branch del nodo Execute Workflow del padre claramente muestra que el elemento está presente. Pero los nodos descendentes conectados al puerto de éxito no se ejecutan. La ejecución simplemente se detiene en Execute Workflow sin error ni enrutamiento adicional.
-
Cuando el subflujo falla: la rama de error se ejecuta correctamente con la carga útil del error. Limpio.
Caso B - Always Output Data ACTIVADO en el nodo Execute Workflow del padre:
-
Cuando el subflujo tiene éxito: ambas ramas, éxito y error, se ejecutan (éxito con los datos reales, pero también una ejecución fantasma de alguna manera).
-
Cuando el subflujo falla: ambas ramas se ejecutan simultáneamente: la rama de éxito se ejecuta con un elemento de marcador de posición vacío
{}, la rama de error se ejecuta con la carga útil del error real. Ambas rutas descendentes se ejecutan en paralelo, lo que causa alertas Telegram duplicadas y páginas de finalización de formulario conflictivas.
Lo que he intentado
-
Activar
Always Output Dataen el nodo terminal Sheets del subflujo ACTIVADO, conAlways Output Datadel Execute Workflow del padre DESACTIVADO. El nodo terminal del subflujo confirma que emite 1 elemento con datos completos cuando se verifica en el registro de subejecución. La pestaña Success Branch del Execute Workflow del padre también muestra ese elemento. Los nodos descendentes aún no se ejecutan. -
Verificar que
Wait for Sub-Workflow Completionestá ACTIVADO. -
Verificar el cableado en el lienzo - puerto de éxito al nodo de limpieza, puerto de error al nodo de alerta. Sin cambios accidentales.
-
Probé ambos modos “Run once for each item” (Ejecutar una vez por cada elemento) y “Run once with all items” (Ejecutar una vez con todos los elementos). Mismo resultado.
-
Redibujar las líneas de conector desde el puerto de éxito. Sin cambios.
Lo que quiero
El patrón estándar de doble salida que la mayoría de las personas parecen usar:
-
El subflujo tiene éxito → solo la rama de éxito se ejecuta descendentemente → se ejecutan limpieza + alerta de éxito.
-
El subflujo falla → solo la rama de error se ejecuta descendentemente → se ejecutan alerta de error + UI de recuperación.
-
Nunca ambas a la vez.
Preguntas
-
¿Es conocido que
Continue (using error output)se comporta mal cuando el nodo terminal del subflujo devuelve elementos pero el puerto Execute Workflow del padre no se propaga a los nodos descendentes? ¿Hay una versión específica de n8n Cloud donde esto está parcheado? -
¿Hay un patrón canónico que la gente usa para obtener un enrutamiento dual limpio - quizás con un nodo Merge, una verificación IF en
$json.error, o algún workaround estructural que me esté perdiendo?
Cualquier indicación será apreciada. Estoy disponible para compartir más detalles de lo que más se necesitaría (como código JSON, capturas de pantalla del flujo de trabajo y otros).
Gracias.