Clarification Needed on Retry On Fail Behavior for HTTP Request Nodes

Questions
1

Hi community,

I am using the HTTP request nodes in n8n, which allow the option to “Retry on Fail.” My understanding is that when an error occurs in the call, the node waits for a few seconds and then retries the call up to 3 times in my current scenario.

However, it is unclear whether a 500 status error triggers the retry mechanism and how I can verify if the node indeed attempted the retries.

I am unsure if this 500 error activates the “Retry on Fail” option and how to be certain that the node actually attempted to retry when errors occur. This uncertainty leaves me wondering whether to rely on the HTTP request node to handle retries automatically or if I should create subsequent nodes to handle specific errors.

Can someone assist me with this dilemma?

Thank you in advance for your help!

Retry_on_Fail
Retry_on_Fail1920×1387 124 KB

Share the output returned by the last node

error
message:500 - “{\n "error": {\n "message": "The server had an error while processing your request. Sorry about that!",\n "type": "server_error",\n "param": null,\n "code": null\n }\n}”
name:AxiosError
stack:AxiosError: Request failed with status code 500\n at settle (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/core/settle.js:19:12)\n at ClientRequest.handleResponse (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/adapters/http.js:537:9)\n at Object.onceWrapper (node:events:632:26)\n at ClientRequest.emit (node:events:517:28)\n at ClientRequest.emit (node:domain:489:12)\n at HTTPParser.parserOnIncomingClient (node:_http_client:700:27)\n at HTTPParser.parserOnHeadersComplete (node:_http_common:119:17)\n at TLSSocket.socketOnData (node:_http_client:541:22)\n at TLSSocket.emit (node:events:517:28)\n at TLSSocket.emit (node:domain:489:12)\n at addChunk (node:internal/streams/readable:368:12)\n at readableAddChunk (node:internal/streams/readable:341:9)\n at TLSSocket.Readable.push (node:internal/streams/readable:278:10)\n at TLSWrap.onStreamRead (node:internal/stream_base_commons:190:23)\n at TLSWrap.callbackTrampoline (node:internal/async_hooks:128:17)\n at Axios.request (/usr/local/lib/node_modules/n8n/node_modules/axios/lib/core/Axios.js:45:41)\n at processTicksAndRejections (node:internal/process/task_queues:95:5)\n at requestFn (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:567:33)\n at proxyRequestToAxios (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:570:26)\n at Object.request (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:1986:50)
code:ERR_BAD_RESPONSE
status:500

Information on your n8n setup

  • n8n version: 1.37.3
  • **Database (default: SQLite):cloud
  • **n8n EXECUTIONS_PROCESS setting (default: own, main):cloud
  • Running n8n via (n8n cloud): cloud
  • **Operating system:Mac OS - 14.2.1
2

It looks like your topic is missing some important information. Could you provide the following if applicable.

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
3

Hey @Eduardo_Moscatelli,

A 500 error should trigger it to run again but if you are telling the node to always output data or to never fail the retry may not work as you are telling the node to continue so it kind of expects you to manually implement your retry logic.

I think we were looking to change this but I don’t think we have implemented it yet.

4

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.