ci: give the race detection job a workable timeout - #111
Merged
Conversation
`go test -race -timeout=90s -count=3 ./ship ./hub` gives each test binary a 90s budget. ./hub needs ~30s per -race run, so -count=3 lands at ~88s locally — inside the budget, but with no headroom at all. On a GitHub runner it tips over and the job fails with `panic: test timed out after 1m30s`, which reads like a deadlock but is only the clock running out mid-suite. The failure is not tied to any one branch: the same job has been flapping on dev for weeks. Raise the timeout to 300s, which is still well inside the job's 15 minute limit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
coverage: 93.092% (+0.03%) from 93.061% — andig:fix/race-job-timeout into enbility:dev |
kirollosnct
approved these changes
Sep 1, 2026
Member
|
Thank you! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
go test -race -timeout=90s -count=3 ./ship ./hubgives each test binary a 90s budget../hubneeds ~30s per-racerun, so-count=3lands at ~88s locally — inside the budget, with no headroom at all:On a GitHub runner it tips over and the job fails with
panic: test timed out after 1m30s. The dump reads like a deadlock, but the goroutines it names are ordinary: therunning tests:header shows onlyTestHubConnectionsServerSuite(2s in), and the two live goroutines are atime.Sleepinside the test and the 500ms delayed-callback goroutine fromHandleShipHandshakeStateUpdate. Nothing is stuck — the clock ran out mid-suite.This is not tied to any one branch. The same job has been flapping on
devfor weeks; run 33413520498 (PR #109, an mdns-only change) is just the latest to hit it.Change
Raise the timeout on that one step to 300s. Still well inside the job's
timeout-minutes: 15. The other-timeout=90ssteps in the file are-count=1or-run-filtered subsets and have plenty of margin.Not addressed here:
./hubspending ~13s of its 30s inTestHandleShipHandshakeStateUpdateTestSuite, where ~25 tests each wait out the hardcoded 500ms delay inhub_shipconnection.go. Making that delay injectable would cut the runtime by a third — worth its own PR.🤖 Generated with Claude Code