Hey community! How it’s been?
Happy to say that over here at BeUni N8N is being heavily adopted and used.
One thing I noticed when using the HTTP node is that the retry on fail switch has a timeout feature. However, it seems that the timeout function is limited to 5000 ms, which sadly is not enough to wait for some API’s to reset. Is this intended? Could the timeout on the retry be increased further than 5000?
Best regards,
Hey @Bruno_Tome!
That’s really good to know! Thank you 
I am not sure if it’s a bug, but we recently released the Wait node. Do you think that it can solve your problem? You will have to modify your workflow to add the Wait node to the mix.
I’ve changed this to a question for now. We can make it a feature request again, if it’s a bug 
@krynble, is there an alternate method? I checked the HTTP Request node and the max. timeout value is 5000ms.
No that was a very deliberate decision back then. The reason is that the workflow keeps on using resources the whole time. If people would set very long values, the chance of n8n crashing would be very high. Now that we have however the new wait functionality in place, theoretically also long retry times like hours would be OK. Sadly would that however also require quite some work to implement that properly.
Just complementing here, you could build a workflow like this (image below)
The wait node can wait for any time, up to a few years if you wish, without actively consuming resources from your n8n instance.
Hey guys!
Oh, I see the problem @jan. Just wanted to make sure this is not some unintended behaviour. About it being implemented, I don’t see a reason for it, for now, as it would postpone more important features, and the behavior expected can be re-enacted using other nodes.
I ended up using the wait node along with comparing the request as it comes (with no regard to the status codes, 2xx & 4xx), using a if to check for errors, and a split in batches to retry when necessary.
Thanks for the info guys! Have a wonderful day!
