Sitelet https://github.com/nodejs/node/issues/2468
Skip to content

Investigate flaky test test-dns #2468

Description

@joaocgreis

Activity

  1. added
    buildIssues and PRs related to Node.js builds or CI infrastructure.
    testIssues and PRs related to Node.js core tests and test infrastructure.
    on Aug 20, 2015
  2. joaocgreis commented on Aug 20, 2015

    @joaocgreis
    MemberAuthor

    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.

  3. Trott commented on Aug 25, 2015

    @Trott
    Member

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

  4. Trott commented on Aug 26, 2015

    @Trott
    Member

    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?

  5. rvagg commented on Aug 27, 2015

    @rvagg
    Member

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

  6. Trott commented on Sep 4, 2015

    @Trott
    Member

    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...

  7. rvagg commented on Sep 4, 2015

    @rvagg
    Member

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

  8. Trott commented on Sep 4, 2015

    @Trott
    Member

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

    All looks good on CentOS 5.

  9. Trott commented on Sep 4, 2015

    @Trott
    Member

    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...

  10. Trott commented on Sep 6, 2015

    @Trott
    Member

    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.

  11. Trott commented on Sep 7, 2015

    @Trott
    Member

    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.

  12. jbergstroem commented on Sep 7, 2015

    @jbergstroem
    Member

    @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

  13. Trott commented on Sep 7, 2015

    @Trott
    Member

    @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?

  14. Trott commented on Sep 7, 2015

    @Trott
    Member

    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.

  15. 16 remaining items

  16. Fishrock123 commented on Sep 10, 2015

    @Fishrock123
    Contributor

    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.

  17. Trott commented on Sep 12, 2015

    @Trott
    Member

    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...

  18. added a commit that references this issue on Sep 12, 2015
  19. Trott commented on Sep 12, 2015

    @Trott
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    buildIssues and PRs related to Node.js builds or CI infrastructure.testIssues and PRs related to Node.js core tests and test infrastructure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions