Nœud Execute Workflow. La branche Success ne déclenche pas les nœuds en aval malgré l'émission de données ; ou les deux branches se déclenchent simultanément quand Always Output Data est activé

Aidez-moi à Construire mon Flux de Travail
,
1

Salut à tous - je rencontre un problème récalcitrant avec le comportement à double sortie du nœud Execute Workflow quand « On Error: Continue (using error output) » est activé. J’espère que quelqu’un a rencontré ce problème et a trouvé un pattern propre.

Configuration

  • Un workflow parent appelle un sous-workflow via Execute Workflow.

  • Paramètres du nœud Execute Workflow :

    • Mode : Run once for each item

    • Wait for Sub-Workflow Completion : ON

    • On Error : Continue (using error output)

  • Le nœud terminal du sous-workflow est une mise à jour Google Sheets.

  • Le parent a deux branches en aval : chemin de succès (nettoyage + alerte Telegram + page de formulaire terminé) et chemin d’erreur (alerte d’erreur Telegram + page d’erreur terminée).

Le comportement que j’observe

J’ai deux modes de défaillance selon le paramètre Always Output Data du nœud Execute Workflow du parent :

Cas A - Always Output Data OFF sur le nœud Execute Workflow du parent :

  • Si le sous-workflow réussit : le nœud terminal (Sheets update) émet 1 élément avec les données de ligne complètes. L’onglet Success Branch du nœud Execute Workflow du parent montre clairement que l’élément est présent. Mais les nœuds en aval câblés au port de succès ne s’exécutent pas. L’exécution s’arrête simplement à Execute Workflow sans erreur et sans routage supplémentaire.

  • Si le sous-workflow échoue : la branche d’erreur s’exécute correctement avec la charge d’erreur. Propre.

Cas B - Always Output Data ON sur le nœud Execute Workflow du parent :

  • Si le sous-workflow réussit : les deux branches (succès et erreur) s’exécutent (succès avec les vraies données, mais aussi une exécution fantôme d’une certaine façon).

  • Si le sous-workflow échoue : les deux branches s’exécutent simultanément : la branche de succès s’exécute avec un élément placeholder vide {}, la branche d’erreur s’exécute avec la charge d’erreur réelle. Les deux chemins en aval s’exécutent en parallèle, ce qui provoque des alertes Telegram en double et des pages de formulaire terminé conflictuelles.

Ce que j’ai essayé

  1. Basculer Always Output Data ON sur le nœud Sheets terminal du sous-workflow, avec le Always Output Data du Execute Workflow du parent OFF. Le nœud terminal du sous-workflow confirme qu’il émet 1 élément avec les données complètes quand il est vérifié dans le log de sous-exécution. L’onglet Success Branch du Execute Workflow du parent affiche aussi cet élément. Les nœuds en aval ne s’exécutent toujours pas.

  2. Vérifié que Wait for Sub-Workflow Completion est ON.

  3. Vérifié le câblage sur le canvas - port de succès vers le nœud cleanup, port d’erreur vers le nœud alert. Aucun échange accidentel.

  4. Essayé à la fois les modes « Run once for each item » et « Run once with all items ». Même résultat.

  5. Redessiné les lignes de connecteur depuis le port de succès. Aucun changement.

Ce que je veux

Le pattern standard à double sortie que la plupart des gens semblent utiliser :

  • Le sous-workflow réussit → seule la branche de succès s’exécute en aval → cleanup + alerte de succès s’exécutent.

  • Le sous-workflow échoue → seule la branche d’erreur s’exécute en aval → alerte d’erreur + UI de récupération s’exécutent.

  • Jamais les deux à la fois.

Questions

  1. Est-ce que Continue (using error output) est connu pour ne pas fonctionner correctement quand le nœud terminal du sous-workflow retourne des éléments mais que le port Execute Workflow du parent ne les propage pas aux nœuds en aval ? Y a-t-il une version spécifique de n8n Cloud où ce problème est corrigé ?

  2. Y a-t-il un pattern canonique que les gens utilisent pour obtenir un routage dual propre - peut-être avec un nœud Merge, une vérification IF sur $json.error, ou un contournement structurel que je ne connais pas ?

Toute indication est appréciée. Je suis heureux de partager plus de détails sur ce qui d’autre serait nécessaire (en tant que code JSON, captures d’écran de workflow et autres).

Merci.

1 « J'aime »
2

Bienvenue @Nick_Vieru dans notre communauté ! Je m’appelle Jay et je suis un créateur n8n certifié.

Le comportement à double branche avec « Always Output Data » activé est une particularité connue - laisse-le DÉSACTIVÉ. Le modèle plus propre : laisse « On Error: Continue (using error output) » tel quel, et ajoute un nœud IF immédiatement après le nœud Execute Workflow vérifiant {{ $json.error !== undefined }}. Les sorties de succès du sous-workflow ne porteront pas d’objet d’erreur ; les sorties d’erreur en porteront. Cela te donne un branchement explicite et propre sans le problème d’exécution fantôme.

Une chose qui vaut la peine d’être vérifiée : assure-toi que le nœud terminal de ton sous-workflow n’avale pas accidentellement l’erreur avant qu’elle n’atteigne le parent - si le sous-workflow a son propre gestionnaire d’erreur qui capture et transforme l’erreur en sortie normale, le nœud Execute Workflow parent ne la verra pas comme une erreur.

3

@Nick_Vieru
veuillez partager votre json.

4

Hé Jay, Merci beaucoup pour ta réponse rapide !

Je vais essayer ce que tu as suggéré et je te dirai si ça a résolu le problème !

1 « J'aime »
6

Merci Jay, ça a marché ! J’ai dû faire quelques ajustements dans le workflow qui s’exécute à l’intérieur du workflow auquel j’avais des problèmes. Fondamentalement, il y avait 2 nœuds supplémentaires qui étaient à la position terminale, et je ne les atteignais jamais car ils avaient aussi une condition, et pour le scénario que j’exécutais, cette condition n’a jamais déclenché. Par conséquent, le nœud terminal n’a jamais été atteint et la branche de succès du workflow exécuté ne pouvait jamais se déclencher car il n’avait jamais eu de retour du workflow qu’il avait exécuté pour confirmer que celui-ci s’était terminé avec succès.

J’ai placé la condition IF à l’intérieur du workflow problématique et j’ai ajouté une branche du nœud condition IF vers une opération nulle (dans le workflow appelé/exécuté à l’intérieur), et ça marche !

1 « J'aime »
7

Content that’s great! Déplacer la condition IF à l’intérieur du sous-workflow est en fait un meilleur modèle - cela garde la logique de branchement autonome, donc le parent n’a pas besoin de connaître la structure interne de ce qu’il appelle.

2 « J'aime »
8

Déjà réparé, merci !

9

Vous êtes très bienvenue ! Si tout fonctionne comme prévu maintenant, n’hésitez pas à marquer la réponse pertinente comme la solution, et passez une excellente journée !

1 « J'aime »
10

Salut, je suis nouveau sur le forum. Comment je peux faire ça ?

1 « J'aime »
11

Oh, ma mauvaise – je viens de réaliser que ce sujet est dans la catégorie « M’aider à construire mon workflow » et non « Questions ».
La fonctionnalité « Marquer comme solution » n’est disponible que dans la catégorie « Questions », c’est pourquoi tu ne vois pas l’option ici.
Merci beaucoup d’avoir voulu marquer une solution, j’apprécie vraiment ! Malheureusement, cette catégorie ne prend pas en charge cette fonctionnalité.