-
Notifications
You must be signed in to change notification settings - Fork 110
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
Add retries when loading config #887
base: develop
Are you sure you want to change the base?
Add retries when loading config #887
Conversation
Thanks for your interest in palantir/policy-bot, @nikola-jokic! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for submitting this - had a few suggestions, but overall I think this approach looks good.
server/handler/fetcher.go
Outdated
fc.ParseError = err | ||
} else { | ||
fc.Config = &pc | ||
ticker.Reset(delay) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use time.After
here instead of manipulating a ticker - I think it will be easier to understand and I don't think there are any performance concerns with allocating a new timer if we're about to sleep for multiple seconds. Go 1.23 also fixed the issue with timers not being GC'd until after they fire.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, I guess I got used to using ticker before 1.23
server/handler/fetcher.go
Outdated
Path: c.Path, | ||
} | ||
if err != nil { | ||
if !os.IsTimeout(err) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be worth re-trying other errors too, for instance if GitHub returns a 500 error or something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this one, I guess the change needs to be done in palantir/go-githubapp since getFileContents receives a response and only propagates the error. In order to check for 500, there must either be an error type to check for on the caller side, or some other way to propagate 500 error somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The go-github
library returns an error for any non-successful status code, so we have two options here without changing the upstream:
- Retry on any error from loading the content and accept that maybe that will sometimes retry things that will still fail
- Use
errors.As
to test for github.ErrorResponse and then check the status code in the response
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated with error check.
lmkwyt
This PR adds a retry mechanism with exponential backoff when fetching config returns a timeout error.
Fixes #506