go: net: Resolver errors on Windows with code `WSATRY_AGAIN`

#!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

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 17 (13 by maintainers)

Commits related to this issue

Most upvoted comments

This issue may also explain the strong Windows bias in the test failures on #38111 and #27992.

Adding a data point: dotnet/runtime retries once without backoff when calling GetAddrInfoExW and getting WSATRY_AGAIN back (code), but this retry attempt is more related to limitations on GetAddrInfoExW which don’t apply to us, because we are using GetAddrInfoW.

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.