HTTP Request Node - Incompatible error handling options

[rthomas6charter]

Bug Description

In the settings dialog of an HTTP Request Node, there are options for:

• Retry on Fail (switch on or off)
  • if switched on, settings for Max. Tries and Wait Between Tries (ms) appear
• On Error - select one of: Stop Workflow or Continue or Continue (using error output)

If Retry on Fail is switched on AND On Error is set to one of the Continue options, Max. Tries and Wait Between Tries (ms) settings are ignored. i.e. Unless **On error" is set to "Stop Workflow," a single failure from the target HTTP service does NOT cause n8n to retry the request, and the workflow continues immediately to the "regular" or "error" output path/node.

To Reproduce

1. Create a workflow with an HTTP Request Node
2. Click the settings / gear icon
3. Enable Retry on Fail and fill in settings for 2+ Max tries and enough Wait Between Tries (ms) time that it is obvious whether the retry is happening (e.g. 3000 ms)
4. Choose either Continue or Continue (using error output) option for On Error
5. Configure the node to call a service that will simulate one or more failed requests and succeed upon retry.
6. Execute the workflow

Expected behavior

If Retry on Fail is enabled, the node should retry the HTTP request the configured number of times, with the configured wait time between tries, BEFORE continuing.

Alternatively (less preferred)...
The settings on the HTTP Request Node should NOT ALLOW both Retry on Fail and a Continue option for On Error

Operating System

Official Docker Container - Base Image (Alpine?) linux/arm64

n8n Version

1.35.0

Node.js Version

18.19.1

Database

PostgreSQL

Execution mode

main (default)

[Joffcom]

Hey @rthomas6charter,

Thanks for reporting this however we currently don't see this as a bug as it is working as intended. If you are using the "on error" option you are then manually handling what to do in the event of an error which could include your own retry logic.

I do however believe that we should change this in the future to include the rety when using the on error option as it would make life easier in some cases.

I have created N8N-7376 as an internal dev ticket to either change this or document how it works and hide the option.

[rthomas6charter]

@Joffcom

...we currently don't see this as a bug as it is working as intended...

Understood. I reported it as a bug because the intent isn't clear in the settings. When "Retry on Fail" is switched on, sometimes, depending on what other settings are selected, it does not "Retry on Fail." IMO, that is a bug.

[Joffcom]

@rthomas6charter that makes sense and is why I have kept it open so we can either change the UI or change the functionality.

[rthomas6charter]

@Joffcom Thanks!! UX is way down my list too when I'm doing the designing and coding, as long as "something" works. It's higher up my list when I'm doing the using, especially when I end up spending time figuring out why something doesn't work like it appears it was meant to work. ;)

n8n is generally WAYYYYY easier to use, and way more capable than any similar tool I've seen, so please accept this as just an effort to help with "deburring."

While the topic is open, consistency might also be a UX factor worth considering. This thread https://community.n8n.io/t/error-handling-at-node-level-detect-node-execution-status-got-created/26791 describes another node (Postgres, not Http) that offers (?previously offered?) a slightly different, and apparently also a little confusing, set of "on fail" options (2 switches, one for retry, the other for continue).