Desculpe, entendo suas respostas e estou ciente de que esta não é a forma como funciona e não é o que a documentação diz, mas para mim é muito lógico que isso seja um problema e não apenas algo que deva ser aceito do jeito que está.
De acordo com a documentação, um nó Respond to Webhook é considerado válido apenas quando pertence a um gatilho Webhook que está explicitamente configurado para “Respond using ‘Respond to Webhook’ Node”
Se essa declaração fosse verdadeira, não haveria razão para um nó Wait ter uma opção para responder usando RWH, porque isso imediatamente viola a regra em sua declaração. Isso significa que ou a documentação e validação de RWH estão erradas, ou a opção RWH do nó Wait está errada.
Altere o Response Mode de Using Respond to Webhook Node para On Received Response Text (ou Json).
Digite sua resposta de sucesso diretamente no nó Wait (por exemplo, {“status”: “success”}).
Exclua o nó Respond success da sua tela.
Isso mantém sua lógica exatamente igual, mas a validação funcionará perfeitamente porque a resposta está contida entirely dentro do nó Wait.
Essa solução não mantém a lógica igual. No meu fluxo de trabalho real, envio o corpo recebido no nó Wait usando REST para um validador, faço instruções If, posso até salvar coisas em um banco de dados. Quero responder 200 apenas quando todas essas coisas forem concluídas com sucesso. Se mudar meu nó Wait para sempre responder 200, o fluxo de trabalho sempre me dará sucesso, mesmo que, por exemplo, a validação falhe.
É por isso que acho que a forma como descrevi é a forma pretendida:
- Tanto o nó webhook quanto o nó Wait têm a opção de responder usando um nó Respond to Webhook (vou chamar de RWH daqui em diante porque é complicado de falar). Logicamente, não há muita diferença entre eles, exceto pelo fato de que um webhook deve ser usado para iniciar um fluxo de trabalho.
- Em qualquer momento, apenas um Wait/Webhook está ativo, aguardando uma solicitação, o que significa que não há ambiguidade lógica sobre qual nó Wait/Webhook um RWH está respondendo.
- É uma feature absolutamente necessária poder receber uma solicitação em um fluxo de trabalho, fazer algumas ações e então responder positiva ou negativamente com base no resultado dessas ações
Na minha opinião, o n8n deve realizar uma análise adequada do gráfico para encontrar RWHs órfãos.
Além disso, se eu enganar a validação para deixar meu fluxo de trabalho rodar alterando o Webhook para responder usando um RWH desnecessário (desnecessário porque poderia bem ser uma resposta imediata) que retorna 200, o fluxo de trabalho se comporta exatamente como descrevi. Abaixo você pode ver uma versão modificada do fluxo de trabalho, em que primeiro o executo normalmente e depois envio um corpo JSON para o nó Wait com uma única propriedade booleana - stuff. Quando stuff é true, uma solicitação GET é feita e então respondo usando o código de status que recebi da solicitação GET (veja o código do nó RWH). Se stuff for false, a solicitação acionando meu nó Wait receberá 400 como resposta
Esse truque é provavelmente o que usarei daqui em diante (não sabia sobre isso ao escrever o post), mas o fato permanece, há um problema claro aqui.