So right now we have a lot of code throughout to handle backoff when rate-limits are exceeded - and it works very well, and I haven't heard a lot bad about it. But, I do have a few problems with it -
The code repeats itself.
The code generally retries only once.
According to the request docs here: https://requests.readthedocs.io/en/latest/user/advanced/#example-automatic-retries - there's a nice Retry system that we can use, which will automagically do exponential backoffs for us. I think we could use this by default, and then just remove the configuration options regarding backoff - just run as fast as you can, and back off when you have to. Maybe with an optional parameter about backoff duration settings?
The library https://urllib3.readthedocs.io/en/stable/reference/urllib3.util.html#urllib3.util.Retry which does those retries has a backoff_factor of 1 - which would give us sleeps of 1, 2, 4, 8 and so on, until we hit backoff_max (10 minutes maybe?) or total (10 retries maybe?). Could also make sense to have a far larger start backoff - 30 seconds, 10 seconds? - because in rate-limiting terms, 1, 2, 4, or 8 seconds isn't going to make a bit of difference.
So right now we have a lot of code throughout to handle backoff when rate-limits are exceeded - and it works very well, and I haven't heard a lot bad about it. But, I do have a few problems with it -
According to the
requestdocs here: https://requests.readthedocs.io/en/latest/user/advanced/#example-automatic-retries - there's a nice Retry system that we can use, which will automagically do exponential backoffs for us. I think we could use this by default, and then just remove the configuration options regarding backoff - just run as fast as you can, and back off when you have to. Maybe with an optional parameter about backoff duration settings?The library https://urllib3.readthedocs.io/en/stable/reference/urllib3.util.html#urllib3.util.Retry which does those retries has a
backoff_factorof 1 - which would give us sleeps of 1, 2, 4, 8 and so on, until we hitbackoff_max(10 minutes maybe?) ortotal(10 retries maybe?). Could also make sense to have a far larger start backoff - 30 seconds, 10 seconds? - because in rate-limiting terms, 1, 2, 4, or 8 seconds isn't going to make a bit of difference.