Uh oh!
There was an error while loading. Please reload this page.
chore: Fix flaky tests with deterministic runs - #4377
Conversation
Signed-off-by: Glenn Lewis <6598971+gmlewis@users.noreply.github.com>
gmlewis
commented
Jul 10, 2026
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@## master #4377 +/- ##
=======================================
Coverage 97.51% 97.51% =======================================
Files 193 193 Lines 19526 19526 =======================================
Hits 19040 19040 Misses 268 268 Partials 218 218 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
stevehipwell
left a comment
There was a problem hiding this comment.
LGTM
@gmlewis as an aside did you consider using synctest to keep the timeout pattern?
gmlewis
commented
Jul 10, 2026
Yes, in fact the agent started out fixing this flaky test by using synctest but then discovered it could completely remove all asynchrony and make the tests fully deterministic without changing their primary objectives without it. |
This PR addresses a recent race failure on Windows demonstrated here:
https://github.com/gmlewis/go-github/actions/runs/29060026853/job/86259654619
The crash was fatal error: bad g->status in ready — a Go runtime bug on Windows + -race, triggered when parallel tests with goroutines/timers complete under heavy load.
Root cause of flakiness: Two rate-limit tests relied on wall-clock timing:
Fix — made both fully deterministic with zero real-time dependencies:
Also fixed a copy-paste bug: "Expected 1 requests" → "Expected 0 requests".