Error Handling: Re-run Failed Nodes Using a Fallback Route
Sometimes external APIs or third-party services can be unstable and return errors. If you're aware of this and want to prevent such failures from interrupting the entire scenario, you can configure a targeted retry for specific nodes. This guide shows how to implement a fallback route that re-attempts the same step and uses the first successful result.
The example below uses a Headless Browser, but this approach works for any node that might return an error.
Scenario Structure:
# | Step | Description |
1 | Trigger | Starts the process once |
2 | Headless Browser (primary) | Executes a task; if it fails, always returns null (when error ignoring is enabled) |
3 | Filter | Passes the result forward if {{4.bodyContent}} != null (i.e., when no error occurred) |
4 | Fallback Route | Triggers if node 4 fails |
5 | Wait | (Optional) Adds a delay before retrying |
6 | Headless Browser (retry copy) | Attempts again — a copy of node 4 |
7 | SetVariable | Stores the first non-null result via ifEmpty(4.bodyContent; 3.bodyContent) |
How to Implement
✅ Step 1: Configure the potentially unstable node (e.g., Headless Browser - #4) Enable the "Ignore errors" option.
This way, if it fails, {{4.bodyContent}} always will be null and the scenario won't stop.
✅ Step 2: Add a filter before combining results Insert a filter between nodes 4 and 5
Filter expression:
{{ 4.bodyContent != null }}
Meaning: "if the primary node returned content, let it pass"
✅ Step 3: Attach a fallback route to node 4
In the fallback route, insert a duplicate of main node
This acts as an alternative attempt.
✅ (Optional) Add a delay before retrying (if needed) Sometimes it’s useful to wait before retrying (e.g., in case of rate limiting or slow loading).
✅ Step 4: Combine results using ifEmpty in SetVariable (node #5)
In SetVariable, create a variable, e.g., finalBodyContent, with this value:
{{ifEmpty(4.bodyContent;3.bodyContent)}}Explanation:
- If
{{4.bodyContent}}is notnull, it’s used.
- If it's
null(the node failed), then{{3.bodyContent}}is used instead.
Insert a Wait node between the fallback route and the retry copy (between F and 3)
Result Check
In the SetVariable node, check this value:
{{ ifEmpty(4.bodyContent; 3.bodyContent) }}
If everything is set up correctly, this will always contain a successful bodyContent, even if the first node failed.
Multiple Retries (if more attempts are needed)
If you expect that the second attempt might also fail (which can happen with highly unstable APIs), simply repeat the retry block and extend the SetVariable with a cascade like:
{{ ifEmpty(4.bodyContent; 3.bodyContent; 7.bodyContent) }}
