Control retry behaviour on 429s for FallbackProviders

[mrwillis]

Sometimes we get 429'd on providers that are in a FallbackProvider collection. It retires which is expected but it seems to retry a lot, causing a lot of requests to the service, and then more rate limits. Is it possible to treat 429s in a FallbackProvider scenario as just pure failures, instead of retrying? Or disable the retry behaviour all together on the provider level?

Thanks!

[ricmoo]

It should be using exponential backoff. I can double check that the algorithm is working. You can also tune the sigma interval and ceiling for the exponential backoff if you use a ConnectionInfo object, I believe.

The v6 connection object provides a lot more flexibility with callbacks to update requests and responses too, as a quick note of things to come. :)

[ricmoo]

Looking at the ConnectionInfo it looks like you are correct. There is no way that high up the stack to manage retries.

I’ll look into it, but might defer this change until v6.