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

Getting the last retry error when cancelled by context #63

Closed
twz123 opened this issue Jun 15, 2022 · 1 comment · Fixed by #96
Closed

Getting the last retry error when cancelled by context #63

twz123 opened this issue Jun 15, 2022 · 1 comment · Fixed by #96

Comments

@twz123
Copy link

twz123 commented Jun 15, 2022

I have a lot of usages for retry-go (still 3.0.0) along the lines of "retry this until it succeeds or the context is done, returning the last encountered error if it didn't succeed."

I've seen the new features added in 4.x. Unfortunately, they don't match my specific use case, of course 😃.

I have a workaround that looks like this:

var lastErr error
retryErr := retry.Do(
	func() error {
		lastErr = someRetriableStuff()
		return lastErr
	},
	retry.Context(ctx),
	retry.Attempts(math.MaxUint), // could probably be retry.Attempts(0) in 4.x?
	retry.LastErrorOnly(true),
)

// Prefer lastErr over retryErr: In case the context was cancelled or timed
// out, retryErr will just be the err of the context, but not the last
// encountered err of the retried function.
if retryErr != nil && lastErr != nil {
	return lastErr
}

return retryErr

I'm wondering if this is something that could be supported natively by retry-go, although I'm not sure how the API could look like, given that there are already quite some interactions between Context, Attempts and LastErrorOnly.

A very simple thing could be PreferContextErrors(false) with its default being true. This would be only effective if both Context and LastErrorOnly(true) are also given. Not a glorious solution, but kinda acceptable. WDYT?

@LorisFriedel
Copy link

Interested as well, it's even more important when you use a timeout context, you want to know when it timed-out!

This issue was closed.
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 a pull request may close this issue.

2 participants