I have a problem with how On Error parameter behave. I use a custom node with the “Continue (using error output)” option on On Error. The custom node experiencing an error but when I check the data stream both the success and error path is filled with data stream. Is this the problem from the custom node or it is an expected behavior?
note: if you look at the image Parsing Crawl4AI HTML experiencing error but for some reason Extraction content failed? node turn green
What is the error message (if any)?
Could not extract main contents of webpage.
Please share your workflow
Information on your n8n setup
n8n version: 2.18.5
Database (default: SQLite): Postgres
n8n EXECUTIONS_PROCESS setting (default: own, main): not sure
Running n8n via (Docker, npm, n8n cloud, desktop app): docker
@ezraluandre thats per-item, not per-node. each item that succeeds exits the main output, each that errors exits the error output. so if your node ran on multiple items with a mix of pass/fail, both paths filling is expected — the green downstream node just means it got the ones that passed.
its only actually wrong if a SINGLE item failed and shows on both. then its the custom node — on a caught error with continueOnFail it should push that item to the error output only, not also to main. check the execute, probably emitting the failed item on both branches.
Short answer: it can be both, depending on what the node received.
Two things to check first:
Error output routing is per item, not per run. If “Parsing Crawl4AI HTML” received more than one item, the items that parsed fine go out the success output and only the failing ones go out the error output. Both branches lighting up in the same execution is expected in that case. Click the node and compare the input item count against the item counts on each of the two outputs.
If it was a single item and both outputs still fired, that points at the community node itself. The error output feature relies on the node either throwing properly or respecting n8n’s continueOnFail contract. A lot of community nodes were written before “Continue (using error output)” existed, and they catch errors internally and push an item like { error: “…” } to the regular output. Combined with the newer option, you end up with error-shaped items on the
success path. Open the items on your success branch: if they contain an error field instead of parsed content, that is exactly what is happening, and it is the node, not you.
Also worth knowing: a node turning green only means it executed and emitted items. Your “Extraction content failed?” node going green just tells you something arrived on that branch, not that the parse actually worked.
The guardrail I use around any community node regardless: right after the success output, add a cheap IF that checks the item actually has the field you need (textContent in your case) and route everything else into the same failure handling as the error branch. Then it does not matter which of the two behaviors the node has on a given day, bad items can never ride down the happy path.
Thanks for your answer @achamm and @syed_noor , the thing is that there’s only 1 items that goes into “Parsing Crawl4AI HTML”. If you look closely on the success path there’s literally 1 item even though “Parsing Crawl4AI HTML” return error, the same goes for error path there’s also 1 item, so both path actually outputting 1 item and I only handling 1 item.
From @syed_noor explanation I believe the problem is the node itself and I hope it won’t affect the workflow downstream since the success path eventually stop at certain path
@ezraluandre it will affect downstream though — that failed item is going down the success path carrying error/partial data, so whatever’s after it processes a bad item. dont count on “it stops eventually”. either fix the node so it stops emitting the failed item on main, or drop an IF/Filter right after the success output to kill items that actually errored before they flow on.
When I said that it doesn’t affect downstream because at some point the workflow is merging and the next node after merging is only taking the correct data so by design it won’t affect downstream workflow but I need to test it again if I want to make sure
@ezraluandre Single item in, one item out of BOTH outputs confirms it: the node is emitting a continueOnFail-style error item on the main output while n8n also routes the error to the error output. So it is the node’s compatibility with the newer option, not your setup.
On “the merge only takes the correct data”: that depends entirely on which mode your Merge node is in, and it is worth two minutes to verify instead of trusting it. Append mode forwards everything it receives, including the bad item. Combine/match modes can still pair the error-shaped item if the fields it matches on exist. And if any node after the merge references data by position or by node name (I noticed some $item(“0”).$node[…] expressions in your workflow), a bad item shifting positions can quietly change what those expressions resolve to even when the “right” data also
arrived.
The test that settles it: pin one URL you know fails, run it, then open the item that actually arrives at the first node after the merge and look at its content. If you see textContent, you are safe by design. If you see an error field, the merge was never filtering, just passing things along.
Either way, the one-node fix removes the need to trust any of this: an IF right after the success output that checks textContent exists, with everything else routed to the same handling as the error branch. Deterministic beats hopeful, especially three nodes upstream of everything else.
