mkht

In my use case, I'm always specifying `Force = $true`. I have never thought it makes sense to specify `$false` for the `Force` parameter. However, as @PlagueHO points out, changing...

## Some additional variation proposals: ### 1. Limit the maximum interval A problem with exponential backoff is that the interval can potentially become very long. For example, this creates an...

@iSazonov Although it is a personal preference, I prefer `-RetryMode ` over the proposed `-RetryBackofStrategy ` in that comment. `RetryBackofStrategy` is a bit long, and I believe there are very...

@CarloToso Thanks for agreeing to my proposal. I understand that.. :-) For the moment I will work on the implementation and submit a PR, but I would like to hear...

@iSazonov Uh, yes, indeed, that is true. In fact, the algorithm I described in my first proposal to give a random jitter of 0 to 1 second may not have...

@iSazonov I am in the negative on that. the exponential backoff could significantly increase the processing completion time that existing scripts expect. I agree with the policy of following curl,...

I have submitted a PR. In my current implementation, the parameter name is `-RetryMode` and the choices are ``. The default mode is `Fixed` to avoid breaking changes. If exponential...

I understand your point of view. I agree with you that exponential backoff is the best retry strategy for service requests. So we need to consider whether to choose exponential...

> We could look more modern implementation in Azure repo. The Azure .NET SDK does not have a standard retry policy and uses retry mechanisms implemented separately for each service,...

I tried to code search the Azure .NET SDK with a focus on algorithms. As far as I could find, there were no algorithms other than fixed, exponential backoff, and...