Skip to content

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

Merged
merged 6 commits into from
Aug 22, 2022

Conversation

gorzell
Copy link
Contributor

@gorzell gorzell commented Aug 22, 2022

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.

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.

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.
Copy link

@aneubeck aneubeck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Contributor

@rylev rylev left a 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;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@rylev rylev left a 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.

Copy link
Contributor

@rylev rylev left a 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!

@rylev rylev merged commit 4d058c7 into Azure:main Aug 22, 2022
@gorzell gorzell deleted the gorzell/retry-non-time branch August 22, 2022 17:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants