-
-
Notifications
You must be signed in to change notification settings - Fork 844
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
RFC: Retries #765
RFC: Retries #765
Conversation
Wow, thank you for putting the time and thought into this that it deserves. Definitely better planned than I had in mind! I look forward to the discussion, but it currently looks very well done and immediately usable, with a very reasonable interface that is small enough to maintain but with the idea to be extensible enough to use in those corner cases some may ask for. As the squeaky wheel, I certainly give my 👍 to it, even if it only gets merged as it stands now! |
✨ Wow, fantastic stuff! ✨ Very impressive. Some initial thoughts...
|
@tomchristie Thanks! Replying to your notes…
I mostly included that requirement here based on @sethmlarson's description, but one possible example might be "if
Yes, I think if we allow modifying the request we'd need to document the constraints it might introduce w.r.t. anything that relies on request "uniqueness".
Well, that would only hold for the first
It retries on the following exceptions: except (
TimeoutError,
HTTPException,
SocketError,
ProtocolError,
BaseSSLError,
SSLError,
CertificateError,
) as e: These count as errors that will
On-but-only-for-connection-failures by default sounds appealing to me! Would handling other times of failures be deferred to an extension of the default
Yes that's a possible implementation too and probably less intrusive.
Or sure, yes. We can probably get away with just having the |
Closing in favor of #778. Thanks for all the feedback so far! :-) |
Retry functionality has already been discussed in #108, and a first draft was tackled in #134, but later abandoned as HTTPX was still at an early stage back then.
I think we're at a good point to start discussing the design of a potential retry functionality? I also remember @StephenBrown2 mentioned it again in one of the threads when we were preparing the 0.11 release, though I just can't find where that was again…
I submit this as a PR so that we can comment and edit the proposal interactively. Contains:
Without even starting a server, trying running the script with:
You should see output similar to...
Happy to discuss!