test: slow down CandidateFinder test to avoid clock race #304
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm attempting to deal with the flaky CandidateFinder test, which I can't replicate locally. I think the main problem here is that we tick the clock inside the test 1 minute per candidate, but the mock sleeps for 1 second per candidate.
The reasons this works most of the time is that the goroutine startup is fast enough to get started and get to the
clock.Sleep
before the timer gets through its ticks. The mock clock will do an actual 1ms sleep for eachAdd
to let the goroutine scheduler catch up, so for most cases we get enough breathing room to get at least oneclock.Add
in after theclock.Sleep
.So there's two things going on in this PR: