test: fix test-net-* error code check for getaddrinfo(3)

[ncopa]

getaddrinfo(3) may (should?) return EAI_AGAIN on DNS errors. Some
systems apparently returns 'ENOTFOUND' so we check both.

This makes the tests work with musl libc which correctly return
EAI_AGAIN.

For valid errors see:
http://pubs.opengroup.org/onlinepubs/009619199/getad.htm#tagcjh_05_06_05

[Trott]

You've actually had these tests fail on Alpine Linux or whatever? It's my impression that the (unfortunate) ENOTFOUND is injected by Node and does not come form any operating system. See, for example,

node/lib/dns.js

Lines 19 to 20 in 4897f94

	// FIXME(bnoordhuis) Remove this backwards compatibility nonsense and pass
	// the true error to the user. ENOTFOUND is not even a proper POSIX error!

[ncopa]

Yes, this test failed:

Path: parallel/test-net-connect-immediate-finish
assert.js:89
  throw new assert.AssertionError({
  ^
AssertionError: 'EAI_AGAIN' === 'ENOTFOUND'
    at Socket.<anonymous> (/home/ncopa/src/node/test/parallel/test-net-connect-immediate-finish.js:14:10)
    at Socket.<anonymous> (/home/ncopa/src/node/test/common.js:395:15)
    at Socket.g (events.js:277:16)
    at emitOne (events.js:91:13)
    at Socket.emit (events.js:183:7)
    at connectErrorNT (net.js:990:8)
    at nextTickCallbackWith2Args (node.js:484:9)
    at process._tickCallback (node.js:398:17)

[ncopa]

I suppose this is a better fix then:

diff --git a/lib/dns.js b/lib/dns.js
index bcf6aae..c139a78 100644
--- a/lib/dns.js
+++ b/lib/dns.js
@@ -20,6 +20,7 @@ function errnoException(err, syscall, hostname) {
   // the true error to the user. ENOTFOUND is not even a proper POSIX error!
   if (err === uv.UV_EAI_MEMORY ||
       err === uv.UV_EAI_NODATA ||
+      err === uv.UV_EAI_AGAIN ||
       err === uv.UV_EAI_NONAME) {
     err = 'ENOTFOUND';
   }

It makes both tests pass.

But as the comment there says, it should probably return the real error instead of inject ENOTFOUND.

[Trott]

But as the comment there says, it should probably return the real error instead of inject ENOTFOUND.

Agreed. That change would be semver-major though so you'd probably want that in a separate commit (and separate PR).

[ncopa]

What prevents this from being merged?

[Trott]

What prevents this from being merged?

If possible, this could use a test for the code change that is not dependent on the operating system. Since we don't run Alpine Linux in CI (continuous integration), it means that someone could change the code to break it again and we'd never know.

Required: At least one collaborator knowledgable enough about the lib/dns.js code to take responsibility for signing off on it with an LGTM ("looks good to me"). Let's try: @bnoordhuis, @cjihrig, and/or @trevnorris...

It also needs a CI run. Any collaborator giving an LGTM can do that.

[trevnorris]

getaddrinfo(3) may (should?) return EAI_AGAIN on DNS errors.

Commit messages should usually be a little more definitive. ;-)

For testing take a look at test/parallel/test-net-connect-options-ipv6.js. That has example usage. Since there's been a code comment in there since forever that we should remove the node specific error message, not sure we want to add another. Maybe should just take the jump and get rid of it? /cc @bnoordhuis

[cjihrig]

+1 to getting rid of it.

[bnoordhuis]

I agree, let's get rid of it.

[ncopa]

@trevnorris @bnoordhuis getting rid of the node specific error message is handled in separate PR, #5196 where it is said that we should deprecate it in v6 and remove it in v7. #5196 (comment)

[cjihrig]

#5196 has already been marked as semver major. You could argue that this is semver major too though. I wonder if we could combine the two by adding the check from this PR and starting the deprecation process.

[ncopa]

ok. I agree that it is better to fix it properly instead of adding more mess.

How about we change the testcase:

diff --git a/test/parallel/test-net-connect-immediate-finish.js b/test/parallel/test-net-connect-immediate-finish.js
index a540373..6114233 100644
--- a/test/parallel/test-net-connect-immediate-finish.js
+++ b/test/parallel/test-net-connect-immediate-finish.js
@@ -3,14 +3,14 @@ const common = require('../common');
 const assert = require('assert');
 const net = require('net');

-const client = net.connect({host: '...', port: common.PORT});
+const client = net.connect({host: '***', port: common.PORT});

 client.once('error', common.mustCall(function(err) {
   assert(err);
   assert.strictEqual(err.code, err.errno);
   assert.strictEqual(err.code, 'ENOTFOUND');
   assert.strictEqual(err.host, err.hostname);
-  assert.strictEqual(err.host, '...');
+  assert.strictEqual(err.host, '***');
   assert.strictEqual(err.syscall, 'getaddrinfo');
 }));

This is also a completely invalid hostname, but it will give same error (EAI_NONAME) on the different platforms. (I have tested musl libc, gnu libc and osx)

[ncopa]

I rebased the patch and changed the testcase instead. Using '***' as invalid hostname goes around the entire problem and we can let the ugly node specific error message alone.

make testwill pass all tests on alpine linux after this.

[trevnorris]

@ncopa '...' and '***' internally return different error codes, correct? So the point would be to ensure they're both still converted to ENOTFOUND.

[ncopa]

@trevnorris that is what my original patch did (#5099 (comment)) but the discussion went in a loop and people are too scared to touch the lib/dns.js so nothing happens, and based on how the #5196 discussion goes, I have lost hope that it will ever happen.

trying to resolve the invalid hostname '...' gives different internal error code on different platforms. (EAI_NONAME or EAI_AGAIN). Trying to resolve the invalid hostname '***' gives same internal error code on all platforms I have tested on.

The ENOTFOUND message is bad in the first place, so I think it is no point to ensure that another internal message that appears on some platforms are converted to the ENOTFOUND for a cornercase hostname nobody should use.

[Trott]

If I understand correctly, the situation is this:

• ... does not return ENOTFOUND on Alpine Linux because, under the hood, the error returned is not one of the three that Node.js converts to ENOTFOUND
• In contrast *** returns ENOTFOUND everywhere.
• There is another PR for getting rid of the invalid and unfortunate ENOTFOUND but that's kind of a big deal change with a lot of probable ecosystem breakage, so it won't actually be in a release for a long time, if ever.

Sooooooo..... our options here are:

• Try to do a fix for Alpine Linux to insure that ... returns ENOTFOUND there. That would basically translate a fourth error into ENOTFOUND. I don't like this because I don't think we want to increase the situations where ENOTFOUND is returned. If we're going to alter the conditions that trigger ENOTFOUND, let's reduce them and not increase them.
• Do a fix for everything else so that ... doesn't return ENOTFOUND. That's risky and that whole conversation is better suited to the other PR about getting rid of ENOTFOUND entirely, because at least the risk there is obvious.
• Ignore the problem and say that we don't fully support Alpine Linux.
• Change the two corner-case tests so that we use *** instead of .... This is the approach taken in this PR.

Among the options, I think the one taken in this PR is the best. LGTM, but I'd like to get a validating LGTM from someone who has worked more with the DNS code (which is why I originally looped in @bnoordhuis, @cjihrig, and @trevnorris).

[ncopa]

@Trott Thank you for a nice summary. I think you completely understand.

• Try to do a fix for Alpine Linux to insure that ... returns ENOTFOUND there. That would basically translate a fourth error into ENOTFOUND. I don't like this

This was my original approach, and I agree. I don't like this either.

• Do a fix for everything else so that ... doesn't return ENOTFOUND. That's risky

Correct. It is by far less risky to use another invalid hostname that gives expected result everywhere.

I will try to also fix this in musl libc, because it does not really make sense to try again on the invalid hostname ....

[rvagg]

We have Alpine in CI at the moment (won't stay if we can't get this sorted out), the EAI_AGAIN errors are the only ones left standing: https://ci.nodejs.org/job/node-test-commit-linux/3804/nodes=ubuntu1604_docker_alpine34-64

[mhart]

@rvagg can you cherry-pick this commit and double check everything passes?

[rvagg]

only one failure https://ci.nodejs.org/job/node-test-commit/3747/ and that was thanks to Jenkins.

[rvagg]

I'm going to lgtm this, it's not very invasive and the logic is sound as far as I'm concerned.

[rvagg]

landed @ 1a1ff77, thanks @ncopa

And when we get this backported to v4.x the Alpine CI machine won't be regularly red!

[MylesBorins]

just backported, aiming to have it in 4.4.7

[mhart]

Heh – looks like @ncopa fixed it in Alpine (3.4.1) too: http://bugs.alpinelinux.org/issues/5725 👍

[MylesBorins]

So it would appear that backporting this to v4.4.7 has cause some serious weirdness for local testing... not sure why it didn't come up until after the release.

I have opened a PR to revert #7503

edit: this was a network issue... please ignore me 😄

[Trott]

@ncopa RFC 2606 reserves the .invalid TLD. Any chance you can confirm that change *** in these tests to host.is.invalid or something like that still works?

[ncopa]

Yes. This works as expected, and IMHO host.is.invalid is much cleaner.