test: give the jobs manager a shutdown budget that survives a loaded machine - #11
Merged
Merged
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
…machine
TestResubmit_IsOnlyAllowedOnce failed rarely on Windows, at seventeen
seconds, with an error that named nothing:
TempDir RemoveAll cleanup: unlinkat ...: The directory is not empty.
No assertion in that test was involved. It never even reached one.
newTestManager gave Shutdown a hard-coded, unscaled two seconds and
discarded the result. Shutdown returns when its timeout expires whether
or not the workers stopped, and says which in the error it returns. Under
a parallel suite two seconds expired routinely, so the cleanup returned
having shut nothing down, and the workers kept writing job records into
the t.TempDir() Go was about to remove. On Windows a directory that is
gaining files cannot be removed, so the test died in cleanup -- long
after the code under test had done its job correctly.
TestResubmit_IsOnlyAllowedOnce was the likeliest victim because it is the
only Resubmit test that spawns a job and does not wait for it, so its
worker is always still running at cleanup.
Two changes. The budget is scaled through internal/testwait like every
other deadline in the suite, so a busy machine gets the slack and a
genuinely stuck worker still fails. And the error is reported instead of
discarded: "N workers still running after 20s" is the one sentence that
identifies this immediately, and throwing it away is what made a shutdown
that shut nothing down look like success.
The same unscaled literal appeared at fourteen other call sites in
internal/jobs and internal/app, all with the same trap. They are scaled
too, so the flake moves to none of them.
Evidence. Forced: with the budget cut to a nanosecond the failure
reproduces 6/6 with exactly the message above. Natural: under four
concurrent full-suite runs it reproduced on the first attempt at 19.26s.
After the fix, 500 iterations under that same load are clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
packetloss404
force-pushed
the
fix/test-shutdown-budget
branch
from
September 5, 2026 19:38
afd5367 to
4aa63cf
Compare
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
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.
Chases down the
TestResubmit_IsOnlyAllowedOncefailure left open after the sharing-violation fix.What it actually was
It failed rarely on Windows, at ~17s, with an error that named nothing:
No assertion in that test was involved. It never reached one.
newTestManagergaveShutdowna hard-coded, unscaled two seconds and discarded the result.Shutdownreturns when its timeout expires whether or not the workers stopped — and says which in the error it returns:Under a parallel suite two seconds expired routinely. The cleanup returned having shut nothing down; the workers kept writing job records into the
t.TempDir()Go was about to remove; and on Windows a directory that is gaining files cannot be removed. So the test died in cleanup, long after the code under test had behaved correctly.TestResubmit_IsOnlyAllowedOncewas the likeliest victim because it is the only Resubmit test that spawns a job and never waits for it — its worker is always still running at cleanup.Fix
internal/testwait, like every other deadline in the suite: a busy machine gets slack, a genuinely stuck worker still fails.internal/jobsandinternal/app. Scaled too, so the flake relocates to none of them.Evidence
go test ./...clean;go vetandgolangci-lint(repo config, truncation disabled) underGOOS=linux,darwin,windows: 0 non-gofmt findings. (gofmtreports every file locally because the working tree is CRLF; that is the known local-only artefact.)Separately: an unrelated flake found while verifying
TestStallGuard_TickKeepsAliveininternal/provideris independently flaky — same class (an unscaled 30ms real-time deadline, ticked every 10ms, which load starves), different package. Reproduced 3 failures in one batch of 25 on a clean tree with none of these changes, so it is not caused by this work and is not fixed here. It needs a different remedy thantestwait(whose 5s floor would make that test take ~13s), so it is left for a deliberate change rather than folded in.🤖 Generated with Claude Code