ci(minimal): raise Go Tests job cap above its own go test timeout - #346
Merged
Conversation
The job capped at 20 minutes while the test step runs go test with -timeout 30m. The runner therefore killed the job ten minutes before Go's own timeout could fire, and Go's timeout is the only thing that prints a goroutine dump naming the stuck test. Every slow run produced conclusion=cancelled with no diagnostic output at all, and cancelled renders as a test failure on the PR even though nothing actually failed. Observed repeatedly in falkcorp/audiobook-organizer (#2311, #2315, and #2319, the last of which was cancelled at exactly 20m16s). Raises the cap to 35 and documents the invariant: the job cap must stay strictly greater than the longest -timeout passed to any go test invocation in the job, plus setup. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JnjSNo2WizbcnrW4pXT2xp
github-actions
Bot
added
size/S
github-actions
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JnjSNo2WizbcnrW4pXT2xp
github-actions
Bot
added
size/M
type:documentation
jdfalk
added a commit
to falkcorp/audiobook-organizer
that referenced
this pull request
Aug 12, 2026
An earlier comment in ci.yml credited the #2311/#2315 conclusion=cancelled failures to the Coverage Floor job and claimed raising it to 35 fixed them. That was wrong. Those cancellations were on Minimal CI / Go Tests (short, race), which is not defined in this repo. The Minimal CI / prefix on a check name means the job comes from a called workflow, here falkcorp/github-common/.github/workflows/reusable-ci-minimal.yml, where the cap was 20 against its own go test -timeout 30m. Measured on #2319: Go Tests (short, race) cancelled at 20m16s while Coverage Floor completed in 13m21s in the same run. Fixed upstream in falkcorp/github-common#346. That workflow exposes no timeout input, so it could not have been fixed from here. The 35 stays because it is independently correct for this job, which runs make test-short with -timeout 25m. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JnjSNo2WizbcnrW4pXT2xp
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
1 participant
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.
The
Go Tests (short, race)job caps at 20 minutes, but its own test step runs:The runner therefore kills the job ten minutes before Go's own timeout can fire — and Go's
-timeoutis the only thing that prints a goroutine dump naming the stuck test. So a slow run can never produce the one artifact that would explain it.The visible symptom is worse than a plain timeout: the run ends as
conclusion=cancelledwith no output, andcancelledrenders on the PR as a test failure even though nothing failed.Observed
In
falkcorp/audiobook-organizer, repeatedly — #2311, #2315, and #2319. The last one is unambiguous:20m16s against a 20m cap, on a docs-only PR. Every other job in that run succeeded.
That repo cannot fix this itself: this workflow exposes no timeout input (
go-version,node-version,go-experiment,system-packages,frontend-working-dir,run-frontend), so the cap is only settable here.Change
timeout-minutes: 20→35ongo-test-shortonly. Every other job's timeout is untouched.The comment states the invariant so this cannot silently regress: the job cap must stay strictly greater than the longest
-timeoutpassed to anygo testinvocation in the job, plus setup. Raising the test timeout without raising the cap makes every slow run undiagnosable again.Scope and risk
Raising a job cap cannot make a passing run fail. It only allows a genuinely slow or hung run to reach Go's timeout and emit the dump that identifies the culprit. Consumers whose suites finish well under 20m are unaffected — the cap is a ceiling, not a delay.
Not addressed here: why the audiobook-organizer suite approaches 20 minutes (its
internal/serverpackage alone is ~500s and sharding it is tracked separately in that repo). This change makes that problem diagnosable rather than hiding it behindcancelled.🤖 Generated with Claude Code
https://claude.ai/code/session_01JnjSNo2WizbcnrW4pXT2xp