I have a series of “enquiry”, “order”, and “booking” workflows from about 50 client sites, which I find N8N is perfect for. I usually set these up to process leads and distribute them to the appropriate systems with the appropriate logging.
I’d like to beef that up, with a SPAM filter.
I’ve found a good filtering service, which gives me exactly what I need, and I’ve integrated it. But I don’t want to risk a failure in that [non-critical] service impeding the [critical] lead processing after that.
Ideally, I’d like all inbound leads to go through this SPAM scoring mechanism, but to enforce say a 5 second timeout limit, and to continue processing with default values if the service delays or errors.
So here’s where my knowledge of N8N is particularly limited. What are my options here?
- Is there a way to tell N8N to continue processing after an error, with default values ( and a “that step failed” state ).
- Can a timeout be set to ensure that an API non-answer is considered a fail? With something like a 598 response code?
- Can I wrap a small series of nodes up as a “function” that encapsulates these timeout rules and default response value, that can be reused by my other Workflows?
- Should this step be placed inline, just after my trigger, or should I branch around it and have it rejoin the main flow with a merge node?
I come from a Zapier background, with a touch of Make, so N8N is a major upgrade of functionality. I’m not even certain where to start looking, much less what best practices here are.
Hi @memetican, there a few mechanisms in n8n you can avail of.
Is there a way to tell N8N to continue processing after an error, with default values ( and a “that step failed” state ).
All n8n nodes would have a Continue On Fail setting. This will prevent n8n from stopping when hitting an error:
Can a timeout be set to ensure that an API non-answer is considered a fail? With something like a 598 response code?
There are different timeout settings in n8n. You can configure a timeout on a workflow level (so have the entire workflow fail when the execution takes too long) or you could set a timeout in the HTTP Request node which would let you specify a timeout for your REST API requests:
If you want to respond to an HTTP Request with a specific status code after hitting a timeout, you can use the Respond to Webhook node (and a corresponding Webhook node receiving requests) for this, provided you enable the Continue on Fail option from above and verify a timeout has occurred:
Can I wrap a small series of nodes up as a “function” that encapsulates these timeout rules and default response value, that can be reused by my other Workflows?
Yes, you can re-use workflows by referencing them in your other workflows through the Execute Workflow node.
Should this step be placed inline, just after my trigger, or should I branch around it and have it rejoin the main flow with a merge node?
This is pretty much up to you. Nodes like the Respond to Webhook node suggested above can handle expressions allowing you to reference incoming data, so they wouldn’t need to use a hard-coded response status code for example. The Merge node can, however, be a bit tricky at times, so it might be easier to simply use multiple branches with individual Respond to Webhook nodes in each branch.