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

Custom retry function? #15

Closed
chmorgan opened this issue Mar 5, 2019 · 4 comments
Closed

Custom retry function? #15

chmorgan opened this issue Mar 5, 2019 · 4 comments

Comments

@chmorgan
Copy link

chmorgan commented Mar 5, 2019

I'd like to implement a custom retry function, one that will cap the delay time at some value vs. having it increase forever, as I'm currently trying to retry forever in a particular service. It doesn't look like that is possible as it would require being able to create a function that takes a parameter of type retry.config.

Is this not in the current model? I'm new to this package so I could easily be missing something.

@JaSei
Copy link
Collaborator

JaSei commented Mar 6, 2019

Hi, I think it is possible

you can define own DelayType (https://github.com/avast/retry-go/blob/master/options.go#L14)

retry.Do(
  func() error {//retryable function},
  retry.DelayType(func(n uint, config *config) time.Duration {
    //my custom delay function
  })

@chmorgan
Copy link
Author

chmorgan commented Mar 6, 2019

@JaSei you'd think so! This produces an 'undefined: config' error. Changing this to:

retry.Do(
  func() error {//retryable function},
  retry.DelayType(func(n uint, retry.config *config) time.Duration {
    //my custom delay function
  })

produces a 'cannot refer to unexpected name retry.config' error.

@chmorgan
Copy link
Author

chmorgan commented Mar 6, 2019

It may be that it is intentional not to expose the config struct, for encapsulation etc, but because its the parameter passed into these handlers it means it isn't possible to define new implementations. Maybe a dev could weigh in on possible approaches? It would seem reasonably ok to expose config to enable these functions to be customized but again I could be missing something and it does expand the public set of types from the package.

@JaSei
Copy link
Collaborator

JaSei commented Mar 22, 2019

please look at #16 - it should be solve the problem

@JaSei JaSei closed this as completed Apr 29, 2019
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

No branches or pull requests

2 participants