Repository navigation
Investigate flaky test test-dns #2468
Description
Activity
- addedbuildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.testIssues and PRs related to Node.js core tests and test infrastructure.Issues and PRs related to Node.js core tests and test infrastructure.
on Aug 20, 2015 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.
It should perhaps be noted that the flaky test is
test/internet/test-dns.jsand nottest/parallel/test-dns.js.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?
could be, on DO you have to be in the right datacenter to get IPv6 and these might not be
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 localhostI 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...@Trott added, care to submit a few runs https://ci.nodejs.org/job/node-test-commit-linux/ to try it out?
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.
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...
Looks like the failure on
fedora22for 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}}whichcommon.isValidHostname()rejects.The FreeBSD boxes are giving an error on this test file because the test for IPv6 lookups with hints uses the
V4MAPPEDflag. The FreeBSD man page forgetaddrinfo(3)says in theBUGSsection: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.
@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
@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
V4MAPPEDflag where it needs to. So if the test is still failing withEAI_BADFLAGSon FreeBSD (and it is) then that is likely indicative of an actual bug in Node. Does that sound about right?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 thatdns.lookup()bypasses this.16 remaining items
Me and @jasnell ran into this while trying to run the tests on awful nodeconf.eu wifi. it's possible that with a connection without full connectivity, these tests get timed out from c-ares, while working when there is no internet at all.
At this point, the only PR remaining to be merged to close out this bug is #2802. It's a pretty straightforward "split up this monolith of too many tests that cumulatively take too long and cause the file to timeout in CI on Windows" thing, so I'm hoping someone will give it the ol'
LGTMsoon-ish...- added a commit that references this issue
on Sep 12, 2015 - added 2 commits that reference this issue
on Sep 15, 2015
Examples of failures:
win2008r2win2012r2centos5-32centos5-64fedora22armv7-ubuntu1404freebsd101-32freebsd101-64