-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP Request Node - Incompatible error handling options #9236
Comments
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 |
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. |
@rthomas6charter that makes sense and is why I have kept it open so we can either change the UI or change the functionality. |
@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). |
Fix got released with |
Bug Description
In the settings dialog of an HTTP Request Node, there are options for:
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
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)
The text was updated successfully, but these errors were encountered: