-
-
Notifications
You must be signed in to change notification settings - Fork 228
Support Retries in the Generated Client #118
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
Comments
So the httpx team seems to have been going back and forth on a retry API for some time. I think we should wait on adding our own retry functionality until they iron it out so we can take advantage of it. Latest issue tracking it is encode/httpx#1141 though this keeps changing. It sure seems like they'll have it in place for 1.0 which they're moving pretty quickly toward. |
Thanks for the follow-up, I understand if |
Looks like this might be possible now via encode/httpcore#221 , but I don't see any clear documentation on how to do it. Anyone is free to give it a shot if they want. Also, it'll be easier to do manually (without inbuilt support here) once #202 is done. |
I found in the documentation that retries (only connection retries) can be used via Custom Transports:
Looking at the changelog, the minimum version to support this is |
Is your feature request related to a problem? Please describe.
It would be nice if the generated client could allow for retry hooks out of the box. For instance, currently when using
requests
we are able to hook into urllib3's retries to automatically retry certain failing status codes like temporary connection issues. Something like:Describe the solution you'd like
It would be great if we could somewhat similarly hook into the underlying retry mechanisms of httpx.
I would be OK exposing the direct hooks to HTTPX's retries, or introducing an abstraction in case the underlying HTTP library changed.
I imagine generated method signatures might look like:
Alternatively, as a superset of retry functionality we could perhaps expose a factory to create the httpx
session
itself since that's how it performs retries and might allow for further configuration.It could also make sense to expose this at the
Client
level instead since I imagine most uses cases would be satisfied with a common configuration.Describe alternatives you've considered
Without hooks into the direct HTTP client itself, the best approximation is to catch
ApiResponseError
s and evaluate the response to attempt a manual retry.The text was updated successfully, but these errors were encountered: