Je suis désolé, je comprends vos réponses et je suis conscient que ce n’est pas ainsi que cela fonctionne et que ce n’est pas ce que dit la documentation, mais pour moi, il est très logique que cela soit un problème et non simplement quelque chose qu’il faut accepter tel quel.
Selon la documentation, un nœud Respond to Webhook n’est considéré comme valide que s’il appartient à un déclencheur Webhook explicitement défini sur « Respond using ‘Respond to Webhook’ Node »
Si cette affirmation était vraie, il n’y aurait aucune raison qu’un nœud d’attente ait une option pour répondre en utilisant RWH, car cela violerait immédiatement la règle de votre affirmation. Cela signifie que soit la documentation et la validation RWH sont incorrectes, soit l’option RWH du nœud d’attente est incorrecte.
Changez le Response Mode de Using Respond to Webhook Node à On Received Response Text (ou Json).
Tapez votre charge utile de réponse réussie directement dans le nœud Wait (par exemple, {“status”: “success”}).
Supprimez le nœud Respond success de votre canevas.
Cela garde votre logique exactement la même, mais la validation passera parfaitement car la réponse est entièrement contenue dans le nœud Wait.
Cette solution ne gardera pas la logique la même. Dans mon flux de travail réel, j’envoie le corps reçu dans le nœud Wait en utilisant REST à un validateur, j’effectue des instructions If, je peux même sauvegarder des choses dans une base de données. Je veux répondre 200 uniquement lorsque toutes ces choses se sont déroulées avec succès. Si je change mon nœud d’attente pour toujours répondre 200, le flux de travail me donnera toujours un succès, même si par exemple la validation échoue.
C’est pourquoi je pense que la façon dont je l’ai décrite est la façon prévue :
- Le nœud webhook et le nœud d’attente ont tous deux l’option de répondre en utilisant un nœud « respond to webhook » (je l’appellerai RWH à partir de maintenant car c’est lourd à dire). Logiquement, il n’y a pas beaucoup de différence entre eux, sauf qu’un webhook doit être utilisé pour démarrer un flux de travail.
- À tout moment, il n’y a qu’un seul nœud wait/webhook actif, en attente d’une requête, ce qui signifie qu’il n’y a pas d’ambiguïté logique quant au nœud wait/webhook auquel un RWH répond.
- C’est une fonctionnalité absolument nécessaire pour pouvoir recevoir une requête dans un flux de travail, effectuer des actions, puis répondre positivement ou négativement en fonction du résultat de ces actions
À mon avis, n8n devrait effectuer une analyse appropriée du graphe pour trouver les RWH orphelins.
De plus, si je contourne la validation en amenant mon flux de travail à s’exécuter en changeant le Webhook pour répondre en utilisant un RWH inutile (inutile car il aurait tout aussi bien pu être une réponse immédiate) qui retourne 200, le flux de travail se comporte exactement comme je l’ai décrit. Ci-dessous, vous pouvez voir une version modifiée du flux de travail, dans laquelle je le démarre d’abord normalement, puis j’envoie un corps JSON au nœud d’attente avec une seule propriété booléenne - stuff. Lorsque stuff est true, une requête GET est effectuée et je réponds ensuite en utilisant le code de statut que j’ai reçu de la requête GET (voir le code du nœud RWH). Si stuff est false, la requête déclenchant mon nœud Wait recevra 400 comme réponse
Cette astuce est probablement ce que j’utiliserai à partir de maintenant (je ne le savais pas au moment de rédiger le message), mais le fait reste qu’il y a un problème clair ici.