-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Improve Internal Logic for Network Retries #4880
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
Conversation
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 like the overall design, just three nitpicks
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 see what you meant now. However it still doesn't fix the core of the issue? If you have infinite_loop=True
, and max_retries > 0
, we're still incrementing retries
even for successful calls.
That particular parameter combination does not happen in our library, but the function should still have correct behavior for all combinations of inputs imo.
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.
ohh nvm there is a guard against that combination of inputs. So it would work. Do tests need updating?
Except for coverage reasons, I don't see a need. this PR doesn't introduce any new functionality that would need testing. test for the existing network retry use cases are already in place :) |
welp, that took a bit of a detour, but ready for re-review now :) |
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.
looks good, just one question 👍🏽
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.
LGTM!
My take on closing #4871 :) Maybe the diff explains my intentions better than my words :D