#!watchflakes
post <- goos == "windows" && `getaddrinfow: This is usually a temporary error`
--- FAIL: TestScript (0.01s)
--- FAIL: TestScript/mod_proxy_errors (0.07s)
script_test.go:282:
# (2022-09-09T21:03:34Z)
# Server responses should be truncated to some reasonable number of lines.
# (For now, exactly eight.) (0.041s)
> ! go list -m vcs-test.golang.org/auth/ormanylines@latest
[stderr]
go: vcs-test.golang.org/auth/ormanylines@latest: unrecognized import path "vcs-test.golang.org/auth/ormanylines": https fetch: Get "https://vcs-test.golang.org/auth/ormanylines?go-get=1": dial tcp: lookup vcs-test.golang.org: getaddrinfow: This is usually a temporary error during hostname resolution and means that the local server did not receive a response from an authoritative server.
[exit status 1]
> stderr '\tserver response:\n(.|\n)*\tline 8\n\t\[Truncated: too many lines.\]$'
FAIL: testdata\script\mod_proxy_errors.txt:10: no match for `(?m)\tserver response:\n(.|\n)*\tline 8\n\t\[Truncated: too many lines.\]$` found in stderr
2022-09-09T20:29:05-54182ff/windows-amd64-longtest
This issue may also explain the strong Windows bias in the test failures on #38111 and #27992.
Adding a data point:
dotnet/runtimeretries once without backoff when callingGetAddrInfoExWand gettingWSATRY_AGAINback (code), but this retry attempt is more related to limitations onGetAddrInfoExWwhich don’t apply to us, because we are usingGetAddrInfoW.See this issue for more context: https://github.com/dotnet/runtime/issues/29935, and specially this comment: https://github.com/dotnet/runtime/issues/29935#issuecomment-736883119.
A casual look in the source code shows that on Unix platforms EAGAIN is used often (and rightly so) https://github.com/golang/go/blob/a2baae6851a157d662dff7cc508659f66249698a/src/internal/poll/fd_unix.go#L166. It’s probably a great idea to handle WSATRY_AGAIN similarly in all windows related code and system calls that might return that error.