-
Notifications
You must be signed in to change notification settings - Fork 843
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
Retry Safe/Read-Only Requests on Timeout #5278
Conversation
@@ -173,13 +173,16 @@ impl RetryExt for reqwest::RequestBuilder { | |||
let max_retries = config.max_retries; | |||
let retry_timeout = config.retry_timeout; | |||
|
|||
let (client, req) = self.build_split(); | |||
let req = req.expect("request must be valid"); |
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.
Previously this would have panicked try_clone below, so this doesn't change the behaviour. The clients shouldn't be constructing requests that fail validation and so panicking here is the "correct" thing to do.
@@ -242,7 +245,9 @@ impl RetryExt for reqwest::RequestBuilder { | |||
Err(e) => | |||
{ | |||
let mut do_retry = false; | |||
if let Some(source) = e.source() { | |||
if req.method().is_safe() && e.is_timeout() { |
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.
Technically we could retry PUT requests as they are idempotent, that is even if repeated they yield the same server-side state, however, in the presence of request preconditions this behaviour I think might be surprising to users even if it is technically correct.
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.
The code and tests look good to me, -- I think we should document this behavior somewhere as well in doc comments if possible
Thank you @tustvold
Which issue does this PR close?
Closes #.
Rationale for this change
This configures automatic retries of timeouts for safe / read-only requests. This not only helps to improve availability, but when combined with a low request timeout can also improve request latencies. In fact AWS recommends doing exactly this here.
What changes are included in this PR?
Are there any user-facing changes?