I’m sorry, I understand your responses and I’m aware that this is not the way it works and not what the docs say, but to me its very logical that this is an issue and not just something that has to be accepted the way it is.
According to the docs, a Respond to Webhook node is only considered valid when it belongs to a Webhook trigger that is explicitly set to “Respond using ‘Respond to Webhook’ Node”
If this statement was true, there is no reason for a wait node to have an option to respond using RWH, because it immediately violates the rule in your statement. This means either the docs and RWH validation are wrong, or the wait node option RWH is wrong.
Change the Response Mode from Using Respond to Webhook Node to On Received Response Text (or Json).
Type your success response payload directly into the Wait node (e.g., {“status”: “success”}).
Delete the Respond success node from your canvas.
This keeps your logic exactly the same, but validation will pass perfectly because the response is contained entirely inside the Wait node.
This solution will not keep the logic the same. In my actual workflow, I send the body received in the Wait node using REST to a validator, i perform If statements, I may even save things in a database. I want to respond 200 only when all of those things successfully completed. If i change my wait node to always respond 200, the workflow will always give me a success, even if for example the validation fails.
This is why I think the way I described it is the intended way:
- Both the webhook node and and wait node have the option to answer using a respond to webhook node (i will call it RWH from now on because its a mouthful). Logically, there is not much difference between them except for the fact that a webhook must be used to start a workflow.
- At any point, there is only one wait/webhook active, waiting for a request, meaning there is no logical ambiguity to which wait/webhook node a RWH responds.
- Its an absolutely necessary feature to be able to receive a request in a workflow, do some actions and then respond positively/negatively based on the outcome of those actions
In my opinion, n8n should perform a proper graph analysis to find orphaned RWHs.
Moreover, if I trick the validation into letting my workflow run by changing the Webhook to respond using an unnecessary RWH (unnecessary because it might as well have been an immediate response) that returns 200, the workflow behaves exactly as i described. Below you can see a modified version of the workflow, in which i first start it normally, and then send a JSON body to the wait node with a single boolean property- stuff. When stuff is true, a GET request is made and then i respond using the status code that i received from the GET request (see the code of the RWH node). If stuff is false, the request triggering my Wait node will receive 400 as a response
This trick is probably what I will use from now on (I didnt know about it when writing the post), but the fact remains, there is a clear issue here.