Investigate flaky test test-dns

[joaocgreis]

Examples of failures:

• win2008r2
• win2012r2
• centos5-32
• centos5-64
• fedora22
• armv7-ubuntu1404
• freebsd101-32
• freebsd101-64

[joaocgreis]

It seems that this test always fails on the platforms where it fails, and always passes where it passes. Perhaps this can be related to the DNS configuration on the machines.

[Trott]

It should perhaps be noted that the flaky test is test/internet/test-dns.js and not test/parallel/test-dns.js.

[Trott]

On the CentOS and Ubuntu failures, it seems likely that the issue (or maybe just an issue?) is that they are not configured for IPv6?

[rvagg]

could be, on DO you have to be in the right datacenter to get IPv6 and these might not be

[Trott]

For the two CentOS 5 setups that fail with this test, I strongly suspect they would be fixed by adding this to /etc/hosts:

::1               localhost.localdomain localhost

I don't think that failure is a bug in Node. I think Node is correctly getting the name resolution response from the operating system.

I guess this is really an issue to open over in the build repo. I'll go do that now...

[rvagg]

@Trott added, care to submit a few runs https://ci.nodejs.org/job/node-test-commit-linux/ to try it out?

[Trott]

Looks like that did the trick. The two CentOS 5 setups are now passing the test.

• https://ci.nodejs.org/job/node-test-commit-linux/479/
• https://ci.nodejs.org/job/node-test-commit-linux/480/
• https://ci.nodejs.org/job/node-test-commit-linux/481/

All looks good on CentOS 5.

[Trott]

By the way, any guidance would be welcome on how I might be able to troubleshoot stuff like this on the CI server without playing quite so many shenanigans. (For example, I submitted a test job with code in it that dumped /etc/hosts so I could see what was in it.)

With 4.0 about to drop, I imagine I should wait until after the dust settles from that and ask again. But just to get the question/request out there while I'm thinking of it...

[Trott]

Looks like the failure on fedora22 for this test is also related to /etc/hosts. The problem is this line:

127.0.0.1 {{fqdn}} {{hostname}}

That causes the lookup to return {{fqdn}} which common.isValidHostname() rejects.

[Trott]

The FreeBSD boxes are giving an error on this test file because the test for IPv6 lookups with hints uses the V4MAPPED flag. The FreeBSD man page for getaddrinfo(3) says in the BUGS section:

The getaddrinfo function as implemented in FreeBSD currently does not support AI_ALL and AI_V4MAPPED flags and returns EAI_BADFLAGS if one of them is specified.

Sure enough, the test fails with EAI_BADFLAGS.

I'll open a PR to skip the one relevant test on FreeBSD and include a comment explaining that if/when the bug is fixed, then the code skipping the test can be removed.

[jbergstroem]

@Trott FWIW, we're not using 7.2-RELEASE (currently on a rc of 10, moving to 10.2 in a few days) -- support for V4MAPPED was removed in more recent versions.

We filtered out this flagged if passed since a while back: https://github.com/nodejs/node/blob/master/lib/net.js#L954

(relevant commit) 9bc2e26

[Trott]

@jbergstroem OK, so if I'm understanding correctly, we shouldn't add code to the test to skip FreeBSD. Node tries to filter out the V4MAPPED flag where it needs to. So if the test is still failing with EAI_BADFLAGS on FreeBSD (and it is) then that is likely indicative of an actual bug in Node. Does that sound about right?

[Trott]

It seems that the code to screen out the flag on FreeBSD is in a private function that is only called by Socket.connect(). It seems that dns.lookup() bypasses this.