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.
[test-parallel] Add t.Parallel() to safe Go test subtests (batch 1) #53083
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uh oh!
There was an error while loading. Please reload this page.
[test-parallel] Add t.Parallel() to safe Go test subtests (batch 1) #53083
Changes from all commits
011224dFile filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This subtest now runs in parallel while mutating the shared package-level Cobra command via
SetOut/SetErr, so sibling subtests can race on the same command object and make help-output assertions flaky.💡 Why this is blocking and how to fix it
compileCmd,disableCmd, and the other entries in this table are global command instances, not per-subtest copies. After addingt.Parallel(), two subtests can interleavecmd.SetOut,cmd.SetErr,cmd.Help(), and the cleanup that restores the old writers. That means one subtest can capture another subtest's output or restore the wrong writer, turning this test into timing-dependent noise.A safe fix is to avoid parallelizing these subtests unless each one works on an isolated command instance. For example, build a fresh command per case instead of reusing globals:
If cloning the command tree is awkward, remove the nested
t.Parallel()here and keep the cases serialized.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[/tdd] Data race: these subtests are parallelized but mutate shared package-level
cobra.Commandglobals (compileCmd,disableCmd, etc.) viacmd.SetOut()/cmd.SetErr(). When subtests run concurrently, multiple goroutines will race to set the output writers on the same shared command object.💡 Fix suggestion
Remove
t.Parallel()from the subtests (line 27), since the parent test already owns the global commands and the subtest loop captures the loop variablecmd— a shared pointer. Parallelizing here is unsafe without creating a freshcobra.Commandper subtest.The safest fix is to remove the
t.Parallel()added to the subtests while keeping the parent-levelt.Parallel()intact.@copilot please address this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Data race: parallel subtests mutate shared package-level
cobra.CommandobjectsThe subtests call
cmd.SetOut(&out)andcmd.SetErr(&out)on package-level variables (compileCmd,disableCmd, etc.) that are shared across all test goroutines. Running these subtests witht.Parallel()will cause concurrent writes to the same*cobra.Command, triggering a data race detectable withgo test -race.To fix, either:
t.Parallel()from these subtests only (keeping the outert.Parallel()is fine), or@copilot please address this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Parallelizing these subtests is unsafe because every case reads from the shared global
rootCmdtree, and Cobra lazily initializes command metadata in ways that are not guaranteed to be concurrency-safe.💡 Why this is blocking and how to fix it
collectCommandTree(rootCmd)returns pointers into the one global command graph. Once the subtests run concurrently, each case is traversing and inspecting the same mutable Cobra objects at the same time. This PR description explicitly avoided parallelizing another Cobra test for exactly that reason, so doing it here reintroduces the same class of flake through a different path.The low-risk fix is to keep these subtests serial, or construct an isolated command tree per test before enabling
t.Parallel(). Relying on read-only access is not enough when the library caches/normalizes fields lazily.Uh oh!
There was an error while loading. Please reload this page.