For any node in any workflow, we need a generic mechanism to catch and handle errors within the workflow – rather than wiring up a separate “error workflow” for these cases.
Specifically, separate error workflows are great when you want to have a generic notification mechanism for alerting on any/all workflow errors (like Send Alert to Slack).
But, separate error workflows are bad when you want to catch specific errors and handle them in a unique way. Why? Because how you handle these errors likely depends on which node in your workflow threw the error. And if that handling logic is divorced from the originating workflow, then now, as a developer, you have to constantly flip between the “main” workflow and the “error” workflow in order to handle/manage unique errors on a node-by-node basis.
From a quality-of-life perspective, it’s much easier to handle node-specific errors when you are editing the main workflow and not as a separate activity later in the development cycle.
Make.com’s error handling has the following different types of “error handling” nodes:
Ignore
Resume
Commit
Rollback
Break
It would be very useful if n8n had any sort of equivalent capabilities within the main workflow (not as a separate error workflow).
For example, let’s say a node throws a very specific error message that you want to catch and handle in a very specific way. It doesn’t feel like that’s currently possible within the original execution of the workflow – why is that important? – because I want to reference state information from earlier nodes that did execute correctly – and I can’t do that if the error handling is in an entirely different execution.
You can make a workflow handle it’s own errors by having a separate pipeline tied to the Error Trigger.
The only catch, is that those errors will be handled in a separate execution.
My thoughts:
Okay, so if you have the error handled in a separate execution and you know the execution ID of the workflow containing the error, then you can essentially pull up the state of that previous execution using an internal n8n API call.
I’m currently looking at the feasibility of this approach.
Okay, I hope this illustrates how awkward custom error handling currently is within n8n workflows.
Here’s an example of a workflow that:
Takes an Airtable record’s field value
Feeds the value into OpenAI as a prompt
Updates a corresponding field value in the same Airtable record with the result
Now, whenever the data from Airtable triggers OpenAI’s content filtering logic, the Basic LLM Chain throws a 400 error.
We then “catch” this error in the Error Trigger and make sure the error is actually a content filtering violation and then update a “error” field within the same Airtable record:
But in order to do this, we have to pull in the entire state of the previous execution into the Error Trigger workflow explicitly, and then also, if any other errors happen (that we didn’t account for), those will get silently dropped for now (which isn’t ideal).
Hey @barn4k , thanks for the clarification. I guess it would help a ton if the On Error mechanism were supported generically across all node types rather than having to build custom error handling on a per-node-type basis. Does that make sense?
