Need Generic Catch Error Mechanism within Main Workflows

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.’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.

Couple of insights per @jan:

  • 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).

It’s not the only option. You can handle the errors within the Node options:

  • Continue is pretty old option, that has been even in the 0.x version
  • Continue using error output is the very new option, but it’s really helps to handle specific errors.

I have some workflows that utilizing that approach

1 Like

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?

Oh, maybe the On Error mechanism does exist across all node types? I’m going to go through and check to be sure…

Okay, this is really weird… I tried using the On Error set to Continue (using error output) and I’m now seeing these sorts of executions:


In this example, the Basic LLM Chain clearly threw an error, but still evaluated the Success path… huh?

I submitted a ticket tracking this issue here: