-
Notifications
You must be signed in to change notification settings - Fork 290
core: Change the RetryPolicy trait to allow waiting on arbitrary things. #1035
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
Previously the only thing that that a retry would wait for was a period of time, i.e. `Duration`. This adds another function to the `RetryPolicy` trait that allows the implementer to wait on any condition they like. The default implementation of the new method provides backward compatibility by just sleeping for a period of time.
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.
👍
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'd like to think about this a bit, but I have some questions in the mean time.
@@ -20,6 +20,13 @@ pub trait RetryPolicy { | |||
fn is_expired(&self, duration_since_start: Duration, retry_count: u32) -> bool; | |||
/// Determine how long before the next retry should be attempted. | |||
fn sleep_duration(&self, retry_count: u32) -> Duration; |
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.
If we have the wait
method, do we need sleep_duration
any more?
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.
It is a convenience for the simpler cases, but I don't think it is strictly required and it may not always be implemented.
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 think this is a fine thing to try - since we're still not guaranteeing backwards compatibility I don't mind letting this through and experimenting with it.
…sed on the type of error encountered.
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.
One small nit, but otherwise looks great!
Co-authored-by: Ryan Levick <[email protected]>
Previously the only thing that that a retry would wait for was a period
of time, i.e.
Duration
. This adds another function to theRetryPolicy
traitthat allows the implementer to wait on any condition they like. The
default implementation of the new method provides backward compatibility
by just sleeping for a period of time.
A real world example of this is flow control. If you are consistently getting errors from the service is too busy, you may want to slow send less requests across multiple threads. Long term it might be better to add a custom policy for this so that you have access to the exact error, but it would also need to be aware of retries that had occurred, and probably sit later in the
Pipeline
. Another option would be to pass the error into this new function.