HTTP Request retries on HTTP 200 when response body contains top-level "error" field and Retry On Fail is enabled

[sergiocarlotto]

Bug Description

The HTTP Request node in n8n performs unintended retry attempts when Retry On Fail is enabled and the API response returns HTTP 200 OK with a field named error at the top level of the JSON body, even when that field has the value null.

I was able to reproduce this behavior in n8n 2.12.0.

In the test I performed, when the response contains "error": null at the top level, the node performs retry attempts even though:

• the HTTP response status is 200 OK
• the response body is valid JSON
• there are no downstream nodes in the workflow
• the endpoint request completed successfully from a technical perspective

If the top-level field name is changed from error to another value, such as test, the retry attempts no longer occur.

This error field is part of the API business contract and should be handled in the workflow logic, not interpreted as a technical endpoint failure.

Tested environment:

• n8n version: 2.12.0
• HTTP Request node version: 4.4

Expected behavior:

The Retry On Fail option should only perform retry attempts when the request actually fails from a technical execution perspective.

A successful HTTP 200 response should not trigger retries just because the response body contains a field named error, especially when that field is part of the API business contract.

Note:
This issue was observed both in HTTP requests to AI services such as Gemini and in simple requests to internal application services. In the case of AI services, the unintended retries caused unnecessary usage and increased platform costs. In internal workflows, each additional retry increased the overall execution time, causing processes that would normally take less than 1 minute to take up to 10 minutes, in addition to generating extra processing costs.

To Reproduce

How to reproduce

1. Create a simple workflow containing only:

• a Manual Trigger
• an HTTP Request node

2. Configure the HTTP Request node with:

• method POST
• Retry On Fail = true
• a simple JSON request body

3. Point the request to a mock endpoint that returns HTTP 200 OK with the following JSON:

{
  "data": {
    "info1": 1492,
    "info2": "2.25.25.18036271983851469861735147216106455887.20220416085708",
    "info3": "CT"
  },
  "error": null
}

4. Execute the workflow manually.

5. Observe that the HTTP Request node performs retry attempts even though the response is HTTP 200 OK.

6. Change only the top-level field name from error to another name, for example:

{
  "data": {
    "info1": 1492,
    "info2": "2.25.25.18036271983851469861735147216106455887.20220416085708",
    "info3": "CT"
  },
  "test": null
}

7. Execute the workflow again.

8. Observe that in this case the retry attempts no longer occur.

Workflow used in the test:

{
  "nodes": [
    {
      "parameters": {},
      "type": "n8n-nodes-base.manualTrigger",
      "typeVersion": 1,
      "position": [
        -112,
        -160
      ],
      "id": "0de3a0e8-c063-4840-9f5e-53133da4afd4",
      "name": "When clicking ‘Execute workflow’"
    },
    {
      "parameters": {
        "method": "POST",
        "url": "https://885077bf-97a9-420c-a307-93cb38beca1a.mock.pstmn.io/test",
        "sendBody": true,
        "specifyBody": "json",
        "jsonBody": "{\n  \"test\": true\n}",
        "options": {}
      },
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.4,
      "position": [
        96,
        -160
      ],
      "id": "61821f5a-4b56-4aaa-b7f8-1b9f2b47938f",
      "name": "HTTP Request",
      "retryOnFail": true
    }
  ],
  "connections": {
    "When clicking ‘Execute workflow’": {
      "main": [
        [
          {
            "node": "HTTP Request",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "HTTP Request": {
      "main": [
        []
      ]
    }
  },
  "pinData": {},
  "meta": {
    "instanceId": "164f8a73c7436bf949e2984e353cd6687f1f3218821cf41bd5def3199d924c4f"
  }
}

Expected behavior

The Retry On Fail option should only perform retry attempts when the request fails due to a technical reason, such as a connection error, timeout, DNS failure, SSL issue, or invalid HTTP response.

A valid HTTP 200 OK response with a valid JSON body should not be interpreted as a failure just because it contains a field named error at the top level of the response, especially when that field is part of the API business contract and may contain a null value.

Business fields present in the response body should be handled by the workflow logic, not by the node’s internal retry mechanism.

Debug Info

Debug info

core

• n8nVersion: 2.12.3
• platform: npm
• nodeJsVersion: 24.14.0
• nodeEnv: undefined
• database: sqlite
• executionMode: regular
• concurrency: -1
• license: enterprise (production)
• consumerId: e20645a8-6703-4813-85b9-d8c74c76ec27

storage

• success: false
• error: true
• progress: false
• manual: true
• binaryMode: filesystem

pruning

• enabled: true
• maxAge: 336 hours
• maxCount: 50000 executions

client

• userAgent: mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/146.0.0.0 safari/537.36 edg/146.0.0.0
• isTouchDevice: false

Generated at: 2026-03-23T14:16:14.050Z

Operating System

Ubuntu 24.04.4 LTS

n8n Version

2.12.3

Node.js Version

24.14.0

Database

SQLite (default)

Execution mode

main (default)

Hosting

self hosted

[n8n-assistant]

Hey @sergiocarlotto,

Thank you for reaching out! We’ve received your issue and are looking into it. To help us track this internally, we’ve created a Linear ticket with the reference: "GHC-7421".

We’ll keep you updated as we make progress, but if you have any additional details or context to share, feel free to add them here - it’s always helpful!

Thanks for your patience and for bringing this to our attention.

---

For INTERNAL use only: GHC-7421