Node Max Tries / Wait Values Limits Too Low about n8n HOT 7 CLOSED

Hey @Joffcom , that's surprising, but sure -- I've submitted the feature request here:
https://community.n8n.io/t/node-max-tries-wait-values-limits-too-low/46284

from n8n.

Hey @dkindlund

This sounds more like a feature request than a bug and would be better suited to the support forum.

As there is not really anything for us to fix here I am going to mark this as closed, When you create the feature request on the forum don't forget to vote to make it count.

Let me know if you have any other questions about this one.

from n8n.

Hey @dkindlund,

Thanks for that 👍

Which bit is surprising? We try to keep GitHub for bugs only and have the feature requests on the forum this helps us prioritise and it means the community can all vote for the feature requests.

from n8n.

Hey @Joffcom, let me explain further... the fact that you use the forum for feature requests is not surprising.

What I find surprising is that this issue isn't a bug to begin with. Setting an arbitrary global upper bound of 5 times and 5000 ms wait per try seems like a bug. Maybe those values were picked back when n8n had perhaps only 20 node types -- but now, with many, many more node types, it seems like a tech debt item.

from n8n.

Hey @dkindlund,

I take a very simplisitic view to what is a bug and what isn't a bug, If something is broken it is a bug. If it is brand new feature or an enhancement to something that already exists it is for the forum.

There are some issues that even cross this line like with the Airtable issues you found with the data being cached in the workflow json leading to larger files and slower responses, This was labelled as a bug as the behavior was not expected.

When we look at this one as we have set a limit in the past and the retries are happening so everything is working as expected and it is not broken.

Interestingly enough I did raise an internal feature request for this a while back as not only do I want to set a higher limit I also want to be able to specify other options like being allowed to increase the timeout on each failure so rather than always being 10 seconds it can grow with each attempt up to 5 minutes or something.

from n8n.

Interestingly enough I did raise an internal feature request for this a while back as not only do I want to set a higher limit I also want to be able to specify other options like being allowed to increase the timeout on each failure so rather than always being 10 seconds it can grow with each attempt up to 5 minutes or something.

Totally makes sense, @Joffcom! Heck, exponential backoff is a common practice these days, so it would make absolute sense to implement that on some node types where the API rate limits are much, much lower.

Bonus points if you could control the retries and wait limits using Expression values (where you're giving the workflow creator the ability to dynamically set these values based on workload specific information).

Otherwise, if a workflow creator wants more granular control over retries, they're forced to implement it themselves within the workflow directly (which is a pain).

Another side thought I had was: Being able to globally set default retry / wait times by node type -- that way, different retry / wait times could be defined for like Postgres versus Airtable. If you want maximum flexibility, perhaps anchoring default retry / wait times to specific credentials for that node type would make a lot of sense, long term.

from n8n.

Expressions would be great as well, I will check the internal request I made to see if that is on there. I like the idea of wait times in credentials as well sounds like a good option for the future.

from n8n.