You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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...
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.
@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.
@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?
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.
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' LGTM soon-ish...
Between machine config changes made by @rvagg in the course of this issue discussion and PRs #2802, #2785, and #2724, this issue is now resolved. Closing.
Activity
joaocgreis commentedon 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.
Trott commentedon Aug 25, 2015
It should perhaps be noted that the flaky test is
test/internet/test-dns.jsand nottest/parallel/test-dns.js.Trott commentedon Aug 26, 2015
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 commentedon Aug 27, 2015
could be, on DO you have to be in the right datacenter to get IPv6 and these might not be
Trott commentedon Sep 4, 2015
For the two CentOS 5 setups that fail with this test, I strongly suspect they would be fixed by adding this to /etc/hosts:
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 commentedon Sep 4, 2015
@Trott added, care to submit a few runs https://ci.nodejs.org/job/node-test-commit-linux/ to try it out?
Trott commentedon Sep 4, 2015
Looks like that did the trick. The two CentOS 5 setups are now passing the test.
All looks good on CentOS 5.
Trott commentedon Sep 4, 2015
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 commentedon Sep 6, 2015
Looks like the failure on
fedora22for this test is also related to/etc/hosts. The problem is this line:That causes the lookup to return
{{fqdn}}whichcommon.isValidHostname()rejects.Trott commentedon Sep 7, 2015
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: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 commentedon Sep 7, 2015
@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 commentedon Sep 7, 2015
@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?Trott commentedon Sep 7, 2015
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
Fishrock123 commentedon Sep 10, 2015
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.
Trott commentedon Sep 12, 2015
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...test: split up internet dns tests
Trott commentedon Sep 12, 2015
Between machine config changes made by @rvagg in the course of this issue discussion and PRs #2802, #2785, and #2724, this issue is now resolved. Closing.
test: split up internet dns tests
test: split up internet dns tests