-
Notifications
You must be signed in to change notification settings - Fork 3.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
More HTTP status codes to retry on #4473
Conversation
…s codes to retry on. This is useful for AWS S3 or Cloudflare, which at times return codes other than 503 for itermitent failures.
setup.py
Outdated
@@ -29,7 +29,7 @@ def find_version(*file_paths): | |||
tests_require = [ | |||
'pytest', | |||
'mock', | |||
'pretend' | |||
'pretend', |
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 has been fixed in master - could you merge master into this PR?
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.
@pradyunsg done, I've merged the latest upstream master
LGTM except for the extra change which I believe has merged into master. |
What do they return for intermittent failure? |
Cloudflare expands the 5xx series with their own errors - https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#Cloudflare; I assumed that that's what this PR is for. |
@dstufft for example S3 would at times return |
My underlying question here is really: Can we just expand our default list to cover these cases to remove the need for an option, or are they going to be status codes where it would be a bad idea to retry in the general case. If they're all 5xx errors, then I think we can probably just allow retries on all of those codes? Given this API is read only, retrying should be completely safe. |
I guess this depends how strictly you want to follow HTTP specs. The reason I'd see it as an option is that under normal circumstances you probably shouldn't retry on That being said, I would be fine with option |
Hello! I am an automated bot and I have noticed that this pull request is not currently able to be merged. If you are able to either merge the |
Like @dstufft I'd be in favor of adding some of those codes to our retry list rather than adding this (very specific) option. |
@vartec It'd be awesome if you could make a new PR (or modify this one) to do what @dstufft and @xavfernandez are suggesting. |
@pradyunsg, @dstufft, @xavfernandez – per your suggestions I've changed it to hardcoded statuses and removed an option |
--retry-status <HTTP code>
to allow specifying custom HTTP status codes to retry on
@vartec It looks like there is a non-ascii character in your comment, breaking the build in python 2 |
@vartec thanks for the PR 👍 |
* Add `--retry-status <HTTP code>` to allow specifying custom HTTP staus codes to retry on. This is useful for AWS S3 or Cloudflare, which at times return codes other than 503 for itermitent failures. * stripping option related code, hardcoding the statuses * Reword the news file * changing ndash to regular ascii dash
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Add
--retry-status <HTTP code>
to allow specifying custom HTTP stauts codes to retry on. This is useful for AWS S3 or Cloudflare, which at times return codes other than 503 for intermittent failures.