@retry should respect 429 Retry-After headers
#238
Labels
Comments
|
Some additional context: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After |
prkumar
added a commit
that referenced
this issue
Jan 6, 2022
Adds a new base class, `uplink.retry.RetryBackoff`, which can be extended to implement custom backoff strategies. Subclasses can override three methods: - `get_timeout_after_response(request, response)`: Returns the number of seconds to wait before retrying the request, or ``None`` to indicate that the given response should be returned. - `get_timeout_after_exception(request, exc_type, exc_val, exc_tb)`: Returns the number of seconds to wait before retrying the request, or ``None`` to indicate that the given exception should be raised. - `handle_after_final_retry()`: Handles any clean-up necessary following the final retry attempt. An instance of a `RetryBackoff` subclass can be provided through the `backoff` argument of the `@retry` decorator. #238
Merged
|
The new |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Discussed in #235
Originally posted by mivade December 20, 2021
RFC 6585 describes the 429 status code to indicate hitting rate limits. This type of response may include a
Retry-Afterheader indicating the time in seconds to wait before trying again. Naively I would expect to be able to define my own backoff function to parse this header and yield that value to indicate how long to wait, but it looks like backoff functions have no knowledge of the response itself. Is there a way to get this functionality?The text was updated successfully, but these errors were encountered: