internal/toolutil/rate_limit_test.go:815 has a case that sets r.throttleWindow = time.Millisecond and then asserts how many refusal lines the limiter emitted across that window. The window is real time, so what the case measures on a busy machine is the scheduler rather than the suppression rule.
It failed once for me during a full go test ./internal/... ./cmd/... that was sharing the machine with six other builds, and did not reproduce afterwards: 8 clean runs of the test alone, 5 of the whole package, and a second full-suite run, all green. So the evidence is one failure plus a mechanism, not a rate.
The mechanism is worth fixing regardless of how often it bites. A millisecond is smaller than a scheduling quantum on a loaded host, so the case can cross its own window boundary before the code under test does, and what fails is the timing rather than the behaviour. Either drive the window from a clock the test controls, the way the manager tests in internal/subscriptions do, or widen it to something no scheduler can overrun; the suppression rule itself does not care which number the window holds.
It predates the current sweeps: the window arrives with the file rename in #482. Recording it rather than fixing it inline because the branch that found it is about internal/tools, and a timing fix in internal/toolutil belongs on its own.
Related: #821, the other intermittent failure found the same way.
internal/toolutil/rate_limit_test.go:815has a case that setsr.throttleWindow = time.Millisecondand then asserts how many refusal lines the limiter emitted across that window. The window is real time, so what the case measures on a busy machine is the scheduler rather than the suppression rule.It failed once for me during a full
go test ./internal/... ./cmd/...that was sharing the machine with six other builds, and did not reproduce afterwards: 8 clean runs of the test alone, 5 of the whole package, and a second full-suite run, all green. So the evidence is one failure plus a mechanism, not a rate.The mechanism is worth fixing regardless of how often it bites. A millisecond is smaller than a scheduling quantum on a loaded host, so the case can cross its own window boundary before the code under test does, and what fails is the timing rather than the behaviour. Either drive the window from a clock the test controls, the way the manager tests in
internal/subscriptionsdo, or widen it to something no scheduler can overrun; the suppression rule itself does not care which number the window holds.It predates the current sweeps: the window arrives with the file rename in #482. Recording it rather than fixing it inline because the branch that found it is about
internal/tools, and a timing fix ininternal/toolutilbelongs on its own.Related: #821, the other intermittent failure found the same way.