8000 Add support for having a maximum retry after wait length. #3233
Conversation
| @@ -335,6 +338,8 @@ def get_retry_after(self, response: BaseHTTPResponse) -> float | None: | |||
| def sleep_for_retry(self, response: BaseHTTPResponse) -> bool: | |||
| retry_after = self.get_retry_after(response) | |||
| if retry_after: | |||
| if self.max_retry_wait_length and retry_after > self.max_retry_wait_length: | |||
| raise MaxRetryWaitExceededError(retry_after_header_value=retry_after) | |||
There was a problem hiding this comment.
The is_retry method probably should be updated too to respect the max_retry_wait_length.
e.g. the responses library relies on it.
There was a problem hiding this comment.
Why? A response can still be a retry response even if its Retry-After header exceeds the limit, right? I don't see why we should raise an error just for checking this.
There was a problem hiding this comment.
A better method name for what you want might be something like is_retriable(), as it suggests checking whether a retry is possible, rather than just determining if a response is of a retry type.
There was a problem hiding this comment.
Having both the is_retry and is_retriable method on the Retry object would be a bit confusing.
But this is being tackled in #2500 though with is_response_retry
Co-authored-by: D-stefaang <58431810+D-stefaang@users.noreply.github.com>
Introducing a new feature that allows you to set a maximum duration for retry wait length using the
max_retry_wait_lengthargument. If a response contains aRetry-Afterheader with value greater than the maximum set andrespect_retry_after_headeris set toTrue, we will raise aMaxRetryWaitExceededError.Fixes #1338