Repository navigation
test(windows): avoid recovered nil-expander hardware faults - #4706
Merged
Merged
Conversation
Windows can corrupt memory when recovering from a hardware fault (golang/go#81238), so skip the nil-pointer panic checks there. This mitigates the flake, it isn't a proven fix for the upstream issue. Assisted-By: cagent
dgageot
marked this pull request as ready for review
October 22, 2026 15:27
trungutt
approved these changes
Oct 22, 2026
aheritier
added
area/tools
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.
Why
TestCreateToolSetOKpanicked inside the JSON encoder pool in a run rightafter the parallel
TestNilTemplateExpanderstarted(https://github.com/docker/docker-agent/actions/runs/39799565867/job/119896119973).
This matches the pattern already mitigated for the OpenAPI and toolinstall
packages in #4614: on Windows, recovering from the hardware-fault panics
these tests deliberately trigger (nil-receiver method calls) can corrupt
memory (golang/go#81238), which then surfaces as an unrelated failure in a
different, parallel test.
This is a mitigation, not a proven fix — the causal link to golang/go#81238
is strongly consistent with the symptoms but not conclusively established.
What
Extend the same narrow Windows skip used in #4614 to the two remaining
deliberate nil-receiver panic assertions:
pkg/tools/builtin/webhook/expander_test.gopkg/tools/builtin/fetch/expander_test.goOnly the
assert.Panicschecks (which force the nil-receiver panic +recover) are skipped on Windows, via a nested
t.Runsubtest. The safenil / typed-nil behavior checks (
assert.Nil,assert.Equal) still rununconditionally. All panic assertions are kept on non-Windows. No
production code changes.
Validation
task build,task test,task lint(Go 1.27.3, golangci-lint 2.14.0)go test -race -shuffle=on -count=100 ./pkg/tools/builtin/fetch ./pkg/tools/builtin/webhook ./pkg/tools/builtin/openapiNative Windows CI passed on Go 1.27.3 windows/amd64:
https://github.com/docker/docker-agent/actions/runs/39802913848/job/119908396054
The test report confirms the safe nil / typed-nil subtests pass and only the
nested fault assertions skip. The full CI gate, Linux tests, lint, and
cross-compilation also passed. This single green run validates the intended
skip behavior, not definitive causality or elimination of every flake.