Very much in agreement with this suggestion.
I am dealing with Marketo which has 3 levels of API limits: max 10 concurrent API calls, 100 API calls per 20 seconds and 100k API calls per day. Hitting each limit would require a different retry timing because if we hit our daily limit then I wouldn't want to retry sooner than 24 hours to be on the safe side while hitting the concurrency limit would allow for a retry in a few seconds.
Send us a ticket, we will try our best to assist you with your problem
Jeffrey DaSilva
Enhancement suggestions for "Retries"
Here are a few enhancement suggestions for "Retries":
(1) Allow the ability to configure retries directly on a step without having to add error handling. Reasoning: Adding error handling just for retries is a bit cumbersome and makes recipes more challenging to read/maintain. It also forces us to handle the error instead of just allow our centralized RecipeOps error handling routine to pick it up.
(2) Allow retry wait time to be based on a data pill from the response of the step. Reasoning: Many rate limiting API calls respond with the number of seconds to wait for rate limiting.
(3) Allow scaling time periods for retries. For example, 3 retries at 1 second, 10 seconds, 100 seconds. Reasoning: Most of the time retries can be repeated immediately and would be successful (e.g. 500 error). However, if something is legitimately down for a short period of time (e.g. applying an API update) you would want to wait much longer.
3 people like this idea