-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement max_retry_wait_length for Retry objects #1587
Conversation
Retry object gets an extra parameter at initalization for max_retry_wait_length and when it calls get_retry_after with a response that contains Retry-After header it checks if the value of that greater than max_retry_wait_length. If it is, then a ExceedingWaitTime exception will be raised.
Codecov Report
@@ Coverage Diff @@
## master #1587 +/- ##
=========================================
Coverage ? 99.73%
=========================================
Files ? 22
Lines ? 1896
Branches ? 0
=========================================
Hits ? 1891
Misses ? 5
Partials ? 0
Continue to review full report at Codecov.
|
@sethmlarson For what it's worth, the Python 3.5 macOS build is failing on the master branch and this pull request because of tox-dev/tox#809 (comment) (not a tox bug, but happens to be mentioned in the tox repository). Indeed, lazy-object-proxy now has a setup_requires dependency which is installed by easy_install. But this uses the Travis macOS OpenSSL which only supports TLS 1.1 while PyPI wants TLS 1.2. |
Cycling to get an automatic rebase for CI |
any update @sethmlarson |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've got some different ideas about the API for this feature. Also need documentation for the feature and another unit test for the copying of Retry objects.
@@ -24,6 +24,7 @@ dev (master) | |||
------------------- | |||
|
|||
* Change ``is_ipaddress`` to not detect IPvFuture addresses. (Pull #1583) | |||
* Implement ``max_retry_wait_length`` for Retry objects. (Pull #1587) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be my bad, but can you put this entry in the proper location.
retry_after = self.parse_retry_after(retry_after) | ||
|
||
if self.max_retry_wait_length != -1 and retry_after > self.max_retry_wait_length: | ||
raise ExceedingWaitTime( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of raising an exception what are your thoughts on limiting the amount of time that would be slept in the sleep_for_retry
method? I guess I don't understand the use-case for raising here.
@@ -173,6 +179,7 @@ def __init__( | |||
history=None, | |||
respect_retry_after_header=True, | |||
remove_headers_on_redirect=DEFAULT_REDIRECT_HEADERS_BLACKLIST, | |||
max_retry_wait_length=-1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's have this default to None
instead of an integer value.
Retry object gets an extra parameter at initalization for max_retry_wait_length[OUT OF DATE] Sorry but this PR received reviews in a time that I didn't have extra time to respond, so closing it.and when it calls get_retry_after with a response that contains Retry-After header
it checks if the value of that greater than max_retry_wait_length. If it
is, then a ExceedingWaitTime exception will be raised.
Fixes #1338