Error details mix data from different items

Questions
1

Problem

The error details of the HTTP Request node are mixing up data from different items.

Let me explain:

I have a list of items (numbered 1 to 4).
I pass them to an HTTP Request node.
For each item the node sends an HTTP Request (GET /item/:item_number).
For one of the items, the response is an error (in our example it’s item #2).
I open the HTTP Request node and look at the error details.
The information given is the following:

Summary: “Bad request - please check your parameters [item 1]”"
Error details > From HTTP Request > Full message: “400 - “{“message”:“error”,“item”:2}””
Error details > From HTTP Request > Request: “{ […] “method”: “GET”, “uri”: “https://foobar.app.n8n.cloud/webhook/random-uuid/**item/3**”, […] }”

In short:

  • the summary says the processing of item 1 failed (that’s wrong).
  • the response from the server says the processing of item 2 failed (that’s correct).
  • the request data shown corresponds to item 3 (again, that’s wrong).

The summary always says the issue is with item 1.
The request data appears to be that of the last item that was processed (it’s more or less random).

This issue makes it impossible to debug errors when processing a lot of items and querying APIs that do not clearly identify the resource in their error message. Of course one can always use a Loop Over Items node or Continue (using error output) to work around the issue but it’s cumbersome.

I would be surprised if no one reported this issue before so I searched as best as I could but did not find anything similar. The closest related issue I found is this one: HTTP Request hard to debug with multiple items/error handling . The complaint there is about missing info, not inconsistent/misleading info.

I provided a client and server workflow that reproduces the issue.
You’ll only have to update the client and server/webhook URLs so that they match,

Client Workflow (where the issue is visible)

Server Workflow (simulates random failures)

Full error output from HTTP Request node

{
“errorMessage”: “Bad request - please check your parameters [item 1]”,
“errorDescription”: “error”,
“errorDetails”: {
“rawErrorMessage”: [
“400 - "{\"message\":\"error\",\"item\":2}"”
],
“httpCode”: “400”
},
“n8nDetails”: {
“nodeName”: “HTTP Request”,
“nodeType”: “n8n-nodes-base.httpRequest”,
“nodeVersion”: 4.3,
“itemIndex”: 1,
“time”: “12/2/2025, 10:36:14 PM”,
“n8nVersion”: “1.121.3 (Cloud)”,
“binaryDataMode”: “filesystem”,
“stackTrace”: [
“NodeApiError: Bad request - please check your parameters”,
" at ExecuteContext.execute (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-nodes-base@file+packages+nodes-base_@[email protected]_asn1.js@5_8da18263ca0574b0db58d4fefd8173ce/node_modules/n8n-nodes-base/nodes/HttpRequest/V3/HttpRequestV3.node.ts:858:16)“,
" at processTicksAndRejections (node:internal/process/task_queues:105:5)”,
" at WorkflowExecute.executeNode (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@[email protected]_@[email protected]_08b575bec2313d5d8a4cc75358971443/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1074:8)“,
" at WorkflowExecute.runNode (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@[email protected]_@[email protected]_08b575bec2313d5d8a4cc75358971443/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1255:11)”,
" at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@[email protected]_@[email protected]_08b575bec2313d5d8a4cc75358971443/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1691:27",
" at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@[email protected]_@[email protected]_08b575bec2313d5d8a4cc75358971443/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:2307:11"
]
}
}

Information on your n8n setup

  • n8n version: 1.122.4 (Latest Stable)
  • Running n8n via: n8n cloud
  • Database (default: SQLite): N/A
  • n8n EXECUTIONS_PROCESS setting (default: own, main): N/A
  • Operating system: N/A
1 Like
2

Items are zero based so [item 1] in the summary is the second input item.

for better understanding change item key in your json to something else like

  return [
    { json: { entity: 1 } },
    { json: { entity: 2 } },
    { json: { entity: 3 } },
    { json: { entity: 4 } }
  ];
1 Like
3

Alright, that responds to half my question, thank you!
What about the response not matching the request though? This is actually the main issue.

This is what n8n displays:
Request: GET /item/3
Response: { “item”: 2 }

Requests are semi-randomly selected. Sometimes you’ll get 1, sometimes 2, sometimes 3.

1 Like
4

i did not understand your issue.

if you remove 400 bad request from second workflow and always return successfully, when you run the first workflow your http node will output an array that contains 4 items in the same order

5

@clubpenon

One more thing. if you want all of four request executed and you have the result/error in output. open setting tab of http node and set On Error field to Continue

image
image1867×922 155 KB

6

Here is a screenshot that hopefully is easier to understand.

Screenshot_20251204_114710
Screenshot_20251204_114710908×492 54.2 KB

The error details say that the node failed on the request for item 3, but it’s the request for item 2 that failed, as shown by the main error message and the server’s response.

In short, n8n’s request error details are wrong.

Here is the updated Client Workflow with items indexed to 0 to match n8n error message convention. This makes it crystal clear what the issue is. Run it multiple times and you will see that the request’s reported item number changes randomly (when it should always be item/2).

1 Like
7

You are right about URL in Request output of Error log detail.

i set a wrong url for HTTP node that results in 404 always. when i run the workflow 4 http request started and the node waiting for 4 of them to finish, so in my case i get “Bad request - please check your parameters [item 0]” in header because item 0 failed and it is the first item but error detail is for the first http request that finished. so we get different error detail in each run. but it is only in the error log and if pass error message to next node they are correct.

it is a bug to me

1 Like
8

Thanks for testing and confirming. Should I submit an issue to github?
I haven’t tested on self-hosted n8n but I think it’s safe to assume it behaves the same.

1 Like
9

I tested it on cloud, but i think it is same in self-hosted.

Go ahead and submit it and let us know the result