Skip to content
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

Change backoff semantics in case of initialBackoff #186

Merged
merged 3 commits into from
Jun 9, 2020

Conversation

willdeuschle
Copy link
Contributor

@willdeuschle willdeuschle commented Jun 8, 2020

A not uncommon pattern is to use an initial backoff that is larger than the default max backoff. For example:

err = retry.Do(ctx, func() error {
	// do things
}, retry.WithMaxAttempts(5), retry.WithInitialBackoff(15*time.Second), retry.WithMultiplier(1))

I'd expect this to retry 5 times, every 15 seconds. However, because the default backoff is 2s, we end up retrying every two seconds.

The proposed change is to use the larger of max backoff or initial backoff in situations where the current backoff is larger than the max backoff.

Explicitly setting your initial backoff larger than your max backoff is nonsensical anyways, so I haven't been able to come up with an example where this change is detrimental.


This change is Reviewable

retry/retry.go Outdated
@@ -247,7 +247,11 @@ func (r *retrier) Next() bool {
func (r retrier) retryIn() time.Duration {
backoff := float64(r.options.initialBackoff) * math.Pow(r.options.multiplier, float64(r.currentAttempt))
if r.options.maxBackoff != 0 && backoff > float64(r.options.maxBackoff) {
backoff = float64(r.options.maxBackoff)
if r.options.initialBackoff > r.options.maxBackoff {
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it be better to set maxBackoff = max(maxBackoff, initialBackoff) in Start() after applying the params so we don't do this check every time, given that the logic would be the same? I might consider this semantic more "construction-time" than "runtime"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I considered that and ultimately chose not to do so because it mucks with what is currently a very clean/understandable Start with initialization and then application of option. I'm happy to put it there instead

retry/retry.go Outdated
@@ -247,7 +247,11 @@ func (r *retrier) Next() bool {
func (r retrier) retryIn() time.Duration {
backoff := float64(r.options.initialBackoff) * math.Pow(r.options.multiplier, float64(r.currentAttempt))
if r.options.maxBackoff != 0 && backoff > float64(r.options.maxBackoff) {
backoff = float64(r.options.maxBackoff)
if r.options.initialBackoff > r.options.maxBackoff {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you include a comment on the InitialBackoff param explaining that if it's larger than MaxBackoff, it will take precedent?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

will do

@bmoylan bmoylan merged commit 3788375 into palantir:master Jun 9, 2020
willdeuschle added a commit to willdeuschle/pkg that referenced this pull request Jun 9, 2020
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.

2 participants