I have a problem with how On Error parameter behave. I use a custom node with the “Continue (using error output)” option on On Error. The custom node experiencing an error but when I check the data stream both the success and error path is filled with data stream. Is this the problem from the custom node or it is an expected behavior?
note: if you look at the image Parsing Crawl4AI HTML experiencing error but for some reason Extraction content failed? node turn green
What is the error message (if any)?
Could not extract main contents of webpage.
Please share your workflow
Information on your n8n setup
n8n version: 2.18.5
Database (default: SQLite): Postgres
n8n EXECUTIONS_PROCESS setting (default: own, main): not sure
Running n8n via (Docker, npm, n8n cloud, desktop app): docker
@ezraluandre c’est par élément, pas par nœud. chaque élément qui réussit sort par la sortie principale, chaque élément qui échoue sort par la sortie d’erreur. donc si ton nœud a traité plusieurs éléments avec un mélange de réussite/échec, les deux chemins qui se remplissent est normal — le nœud en aval vert signifie juste qu’il a reçu ceux qui ont réussi.
c’est seulement vraiment faux si UN SEUL élément a échoué et apparaît sur les deux. alors c’est le nœud personnalisé — sur une erreur capturée avec continueOnFail, il devrait envoyer cet élément à la sortie d’erreur seulement, pas aussi à la sortie principale. vérifie la fonction execute, elle émet probablement l’élément défaillant sur les deux branches.
Réponse courte : cela peut être les deux, selon ce que le nœud a reçu.
Deux choses à vérifier en premier :
L’acheminement de la sortie d’erreur se fait par élément, non par exécution. Si « Parsing Crawl4AI HTML » a reçu plus d’un élément, les éléments qui ont été analysés correctement sortent par la sortie de succès et seuls les éléments défaillants sortent par la sortie d’erreur. Les deux branches s’allumant lors de la même exécution est normal dans ce cas. Cliquez sur le nœud et comparez le nombre d’éléments en entrée avec les nombres d’éléments sur chacune des deux sorties.
S’il s’agissait d’un seul élément et que les deux sorties ont quand même déclenché, cela pointe vers le nœud communautaire lui-même. La fonctionnalité de sortie d’erreur dépend du fait que le nœud lance correctement une exception ou respecte le contrat continueOnFail de n8n. Beaucoup de nœuds communautaires ont été écrits avant que « Continue (using error output) » n’existe, et ils capturent les erreurs en interne et poussent un élément comme { error: “…” } vers la sortie normale. Combiné avec l’option plus récente, vous finissez avec des éléments ayant la forme d’erreurs sur le chemin de succès. Ouvrez les éléments de votre branche de succès : s’ils contiennent un champ error à la place du contenu analysé, c’est exactement ce qui se passe, et c’est le nœud, pas vous.
Cela vaut aussi la peine de savoir : un nœud qui devient vert signifie seulement qu’il a été exécuté et a émis des éléments. Votre nœud « Extraction content failed? » qui devient vert vous dit simplement que quelque chose est arrivé sur cette branche, pas que l’analyse a réellement fonctionné.
La garde-fou que j’utilise autour de tout nœud communautaire, peu importe : juste après la sortie de succès, ajoutez un IF simple qui vérifie que l’élément a réellement le champ dont vous avez besoin (textContent dans votre cas) et dirigez tout le reste vers le même traitement des défaillances que la branche d’erreur. Ensuite, peu importe quel comportement le nœud a un jour donné, les mauvais éléments ne peuvent jamais emprunter le chemin heureux.
Merci pour votre réponse @achamm et @syed_noor, le problème c’est qu’il n’y a qu’1 élément qui entre dans « Parsing Crawl4AI HTML ». Si vous regardez attentivement le chemin de succès, il y a littéralement 1 élément même si « Parsing Crawl4AI HTML » retourne une erreur, c’est la même chose pour le chemin d’erreur où il y a aussi 1 élément, donc les deux chemins produisent effectivement 1 élément et je ne traite que 1 élément.
D’après l’explication de @syed_noor, je crois que le problème vient du nœud lui-même et j’espère que cela n’affectera pas le flux de travail en aval puisque le chemin de succès s’arrête finalement à un certain chemin
@ezraluandre cela affectera cependant la suite du flux — cet élément en échec emprunte le chemin de succès en transportant les données d’erreur/partielles, donc tout ce qui suit traite un mauvais élément. ne compte pas sur « ça s’arrête finalement ». soit tu corriges le nœud pour qu’il arrête d’émettre l’élément en échec sur la sortie principale, soit tu ajoutes un IF/Filter juste après la sortie de succès pour supprimer les éléments qui ont réellement échoué avant qu’ils ne continuent dans le flux.
Quand j’ai dit que ça n’affecte pas la suite du flux de travail parce qu’à un moment donné le workflow fusionne et le nœud suivant après la fusion ne prend que les bonnes données, donc par conception ça n’affectera pas la suite du workflow, mais je dois le tester à nouveau si je veux en être sûr
@ezraluandre Un seul élément en entrée, un élément en sortie des DEUX outputs le confirme : le nœud émet un élément d’erreur de style continueOnFail sur la sortie principale tandis que n8n achemine aussi l’erreur vers la sortie d’erreur. C’est donc la compatibilité du nœud avec l’option plus récente, pas votre configuration.
Sur « la fusion ne prend que les données correctes » : cela dépend entièrement du mode dans lequel se trouve votre nœud Merge, et ça vaut le coup de vérifier en deux minutes au lieu de lui faire confiance. Le mode Append transmet tout ce qu’il reçoit, y compris le mauvais élément. Les modes Combine/match peuvent encore associer l’élément en forme d’erreur si les champs sur lesquels il correspond existent. Et si un nœud après la fusion référence des données par position ou par nom de nœud (j’ai remarqué quelques expressions $item(“0”).$node[…] dans votre workflow), un mauvais élément qui change de position peut tranquillement modifier ce que ces expressions résolvent même quand les « bonnes » données sont aussi arrivées.
Le test qui règle la question : épinglez une URL qui échoue, exécutez-la, puis ouvrez l’élément qui arrive réellement au premier nœud après la fusion et regardez son contenu. Si vous voyez textContent, vous êtes sûr par conception. Si vous voyez un champ d’erreur, la fusion n’a jamais filtré, elle a juste laissé passer les choses.
De toute façon, le correctif à un nœud supprime le besoin de faire confiance à tout cela : une IF juste après la sortie de succès qui vérifie que textContent existe, tout le reste étant acheminé vers le même traitement que la branche d’erreur. Le déterministe vaut mieux que l’espoir, surtout trois nœuds en amont de tout le reste.
