Erreur : Le workflow Error Trigger ne se déclenche pas dans n8n 2.36.8 auto-hébergé (l’exécution du Webhook de production échoue)
J’apprends n8n sur une installation auto-hébergée (Docker) et je suis bloqué avec le workflow Error Trigger.
Configuration
Version de n8n : 2.36.8 (Auto-hébergé via Docker)
Workflow principal : Webhook (POST) → HTTP Request → Gmail
Workflow de gestion des erreurs : Error Trigger → Gmail
La requête HTTP appelle intentionnellement :
http://host.docker.internal:9999/fake-api
de sorte qu’elle échoue avec ECONNREFUSED.
Ce que je essaie de réaliser
Quand le workflow principal échoue, je veux que le workflow de gestion des erreurs (Error Trigger → Gmail) s’exécute et m’envoie un email d’alerte.
Ce que j’ai déjà vérifié
Les deux workflows sont publiés.
Le workflow principal est configuré pour utiliser le workflow de gestion des erreurs dans Paramètres du workflow → Error Workflow.
Je déclenche le Webhook de production (/webhook/error-test), pas l’URL de test.
Postman reçoit : {"message":"Workflow was started"}
Le workflow principal apparaît dans Executions et échoue avec ECONNREFUSED.
Cependant, le workflow de gestion des erreurs affiche toujours 0 exécutions, et aucun email n’est envoyé.
Ma question
Me manque-t-il un paramètre requis pour Error Trigger dans n8n 2.36.8, ou y a-t-il une limitation avec l’auto-hébergement/Docker dans cette version ? Y a-t-il quelqu’un qui a réussi à faire fonctionner Error Trigger avec des défaillances de webhook de production dans cette configuration ?
Bonjour @aman_07 Bienvenue !
Le workflow d’erreur se déclenche lorsque l’exécution se termine en erreur, non pas lorsqu’un nœud devient rouge. Si le nœud HTTP Request a On Error défini sur n’importe quelle valeur autre que Stop Workflow, n8n enregistre l’échec par rapport au nœud et termine quand même l’exécution comme Success, et rien n’est déclenché. Ouvrez l’exécution échouée et lisez l’état sur l’exécution elle-même plutôt que sur le nœud.
Si cela affiche réellement Error, la prochaine chose utile à savoir est si vous exécutez en mode queue. Le rapport précédent de cela sur Docker auto-hébergé s’est résolu lorsque cette instance est passée de queue au mode régulier :
Si l’exécution elle-même affiche une erreur, chaque échec de dispatch enregistre une ligne, alors vérifiez plutôt que de deviner :
is not active and cannot be executed signifie que le workflow d’erreur n’a pas de version publiée active. Le sélectionner dans les paramètres de l’autre workflow ne suffit pas, le workflow Error Trigger doit être actif lui-même. Cause la plus courante.
Could not find workflow signifie que le paramètre pointe vers un id obsolète, resélectionnez-le dans la liste déroulante.
Un message de permissions signifie que la politique d’appelant l’a bloqué, ce qui se produit lorsque les deux workflows se trouvent dans des projets différents. Définissez qui peut l’appeler dans les paramètres du workflow d’erreur.
Aucune ligne du tout signifie qu’aucune tentative n’a été faite, donc rouvrez les paramètres du workflow principal, confirmez que le workflow d’erreur est toujours sélectionné, enregistrez et republier.
Rien dans le suivi ne correspond à cela sur 2.3x, donc ce n’est pas un bug connu que vous pouvez attendre.
Il vaut mieux diviser le problème plutôt que de vérifier davantage de paramètres. Créez un flux de travail jetable avec un Déclencheur de planification défini à chaque minute dirigé vers un nœud Stop et Error, assignez le même gestionnaire d’erreur dans ses paramètres, et publiez-le.
Si le gestionnaire s’active pour cela, la distribution fonctionne sur votre instance et cela est spécifique aux exécutions initiées par webhook, ce qui est une chose beaucoup plus étroite à signaler.
Si elle ne s’active pas non plus, la distribution est cassée au niveau de l’instance et la requête HTTP et le webhook sont tous deux des faux pistes.
Ce résultat est le premier fait qui distingue les deux, et c’est ce qu’un rapport de bug doit contenir.