ErrLookup › Background articles › NodeOperationError in n8n: what the wrapped error means, and how to find the real cause behind it

NodeOperationError in n8n: what the wrapped error means, and how to find the real cause behind it

NodeOperationError is n8n's standard error class for a node-level operation failure: almost every error raised inside a node's execute path — API rejections, validation failures, invalid router dispatches, exceeded limits — either is one or gets re-wrapped into one with the node name and itemIndex attached. You meet it when a workflow execution halts (or, with Continue On Fail enabled, when an item comes back with error output), and the message you see may be the original error's text, a rewritten friendlier version of it, or a generic wrapper. The records also show mem0 surfacing the same class for server config validation, so exact semantics are library-specific.

Distilled from 226 documented records across 2 repositories.

Background

NodeOperationError sits at the node layer of n8n's execution engine. Individual nodes (and the shared router loops that drive them, e.g. in the Anthropic, AlibabaCloud, and Google Gemini nodes) run each input item through an operation function; when that function throws and Continue On Fail is off, the router catches the error and re-throws it as a NodeOperationError carrying the current itemIndex and, where present, the original error's description. This is the catch-all that guarantees every failure carries item-level context — the execution UI can point at the exact input item that failed. The original error's message typically becomes the NodeOperationError's message, so the first diagnostic step is always to read message and description plus the itemIndex in the error context.

From the caller's side the family looks different depending on which of four shapes produced it. First, the plain re-wrap: the message is verbatim the underlying failure (rate limit, auth, parse error), and the wrapper only adds context. Second, deliberate validation throws: the node checks its own parameters before doing work — an empty 'text' prompt in the OpenAi Assistant or Plan & Execute Agent nodes, missing 'Supply Data' code in the Code node, an empty embedding query — and halts with a specific message. Third, rewritten provider errors: the node pattern-matches an upstream API response and replaces it with a friendlier message — OpenAI's 'Expected file to have JSONL format' 400 becomes a JSONL explainer, a gateway's 'model not found' becomes a message naming the model and baseURL, Anthropic sampling-parameter deprecation 400s become instructions to remove Temperature/Top K/Top P, and ChromaDB dimension mismatches gain a remediation description. Fourth, router defaults: every resource/operation switch has a default branch that throws 'The operation/resource X is not supported', normally unreachable via the UI but reachable through hand-edited workflow JSON, stale node versions, or expressions that resolve to unexpected values.

Several records document quirks worth knowing. The 'operation not supported' messages in the Anthropic and Gemini routers actually interpolate the resource value, not the operation, so the reported value is not the thing that failed. The 'No binary data exists on item!' check in the Analyze Image operation is dead code — helpers.assertBinaryData() throws first. And because router catch blocks are untyped, a non-Error throw (a string or plain object) passed directly as the message can surface as '[object Object]'. The two mem0 records show the same class used for upfront config validation (rejecting LLM/embedder providers not bundled in the Docker image), a behavior specific to that library rather than n8n's item-processing model.

Common causes

What usually fixes it

Go deeper

Documented occurrences

…and 206 more across the corpus — use search.

Honest provenance: generated on 2026-08-15 from AI-assisted analysis of the linked records. See how records are made.