the func DialWithTimeout panic with MacOS + Go 1.12

[boostbob]

Mac + Go 1.12:

call mgo.DialWithTimeout:

[14:27:00][DISCOVERY] : panic: no reachable servers

not always timeout，the go 1.11 or linux won't throw this error.

[NeoyeElf]

I hava encounter the same problem with mgo.Dial(url string)

env: Mac + Go 1.12

[itytwt]

No sure if it is the same issue.

In our case, we define mongo as 127.0.0.1 in /etc/hosts on development machine and pass mongo:27017 as DialInfo.Addrs to the driver, and it seems that address resolving has unexpected behavior during dialing on mac with Go 1.12.

This can be checked by enabling mgo log:

var buf bytes.Buffer
mgo.SetLogger(log.New(&buf, "", log.Lshortfile))
if _, err := mgo.DialWithInfo(info); err != nil {
	panic(err)
}
fmt.Printf("%v\n", &buf)

The root cause points to consecutive failure-and-retry of function resolveAddr in cluster.go, and the failure is resulted from unsuccessful net.DialTimeout calls with "udp4", which is expected to work.

Some experiments show that the part of attempting to resolve v4 and v6 address concurrently in function resolveAddr does not fail randomly with Go 1.11 and other OSs. You may play around with the snippet to see what happens.

It seems that this is a Go net package issue instead of mgo driver.

[baloo32]

Just encountered same issue with Dial on Windows platform (Golang 1.12.1 and MongoDB 3.6.11) so not just on MacOS.

Rolling back Go to 1.11.5 fixes issue and seems to be latest available working version of Golang.

[baloo32]

Update from Golang issues tracker:

Sounds like the DNS stub resolver is broken in Go 1.12 and 1.12.1. Can you please confirm that the issue still happens when GODEBUG=netdns=go on non-Windows platforms. If not, the root cause is probably #30521.

Can anyone on non-Windows platform try setting the GODEBUG flag under 1.12/1.12.1 and see if issue persists - I will then feedback to Golang issue.

[itytwt]

Pure Go resolver works on mac here.

[roy-michael]

when using the GODEBUG=netdns=go on Mac OS X 10.14.18A391 with go1.12.1 darwin/amd64 the issue is resolved.

[domodwyer]

Hi all,

Top debugging! I'm going to close this - it definitely sounds like golang/go#30521

Thanks!
Dom