fix: support authority overrides in the DNS resolver

[gkampitakis]

As per issue #2775, this pr adds support for overriding the authority on DNS resolver.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: gkampitakis / name: Georgios Kampitakis (3aaf0c6, 201595c, 717725c, a9aea45, 7f27b32, 6278da6, 2a9f8f4, c9fc8b2, cb58fbc, c3d073b, e2a93d1, f0afe69)

[gkampitakis]

I have updated per recommendation the lookup method to resolve explicitly both ipv4 and ipv6. I see there are some unit tests but are skipped, what would be your suggestion for that matter? @murgatroid99

[gkampitakis]

@murgatroid99 code has been update per your feedback, thank you. I have also tested locally and it does behave as expected.

Are there any

• tests that need to be added/updated
• docs added/updated

[MartinLoeper]

This feature is fantastic. Thanks so much for implementing it @gkampitakis! 🥳

[murgatroid99]

For documentation, this file should be updated with the new environment variable.

In terms of testing, ideally there would be at least some automated testing for this code path. I think running the entire test suite is impractical, because I believe the alternate resolver can't resolve the address localhost, which many of the tests use. This file has the most relevant tests, but it also has a few that won't work because of the localhost issue. So, I think it would make sense to test with just that file, with those localhost tests skipped if the environment variable is set.

[gkampitakis]

@murgatroid99 I don't see an example of how to test this code path (using an env variable).

To make this testable with no weird monkey patching the import I would have to rework the code and pass this env variable as a parameter but again I don't see any good pattern in the code base? Any suggestions for tackling the testing here?

[murgatroid99]

OK, for testing I was thinking that a gulpfile target could be added that runs just that one test file with the environment variable set. Then the actual test target would run both tests in sequence.

[gkampitakis]

OK, for testing I was thinking that a gulpfile target could be added that runs just that one test file with the environment variable set. Then the actual test target would run both tests in sequence.

That makes sense. I am not very familiar with this setup. Thanks for the advice. I have added the new test but on my machine the timeouts are quite flaky, but didn't want to "touch" them without understanding what's happening there.

[murgatroid99]

The tests that try to resolve localhost need to be skipped when using the alternate resolver. You can do this by changing the test declaration to use function(done) {...} and adding this to the test body:

if (GRPC_NODE_USE_ALTERNATIVE_RESOLVER) {
  this.skip();
}

[murgatroid99]

This shouldn't be necessary. This test expects DNS resolution to fail, and this option only takes effect if it succeeds.

[gkampitakis]

For this test I am getting error without this value. I assume it allow us to "retry" resolution faster but probably it's another issue.

Uncaught AssertionError [ERR_ASSERTION]: resultCount 1 !== 2
      + expected - actual

      -1
      +2
      
      at Timeout._onTimeout (test/test-resolver.ts:477:16)
      at listOnTimeout (node:internal/timers:569:17)
      at processTimers (node:internal/timers:512:7)

Also getting timeouts on, should I increase the value?

  Should resolve gRPC interop servers:
     Error: Timeout of 4000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/Users/george.kampitakis/Dev/grpc-node/packages/grpc-js/build/test/test-resolver.js)
      at listOnTimeout (node:internal/timers:569:17)
      at processTimers (node:internal/timers:512:7)

[gkampitakis]

Can't tell if the failing tests are related to my changes 🤔

[murgatroid99]

Unfortunately, I think this is impacting other test jobs. I think this alternative will work: create a new file called something like alternate-resolver.env that just says GRPC_NODE_USE_ALTERNATIVE_RESOLVER=true and add an option in the mocha command a couple of lines down that says nodeOption: 'env-file=alternate-resolver.env'.

[gkampitakis]

If you are referring to this, I don't see a nodeOption or something similar from the documentation.

mocha({
    reporter: 'mocha-jenkins-reporter',
    require: ['ts-node/register'],
  })

[murgatroid99]

That is what I'm talking about. The gulp-mocha documentation says

Options are passed directly to the mocha binary, so you can use any its command-line options in a camelCased form.

The mocha command line options documentation includes this line:

 -n, --node-option  Node or V8 option (no leading "--")                 [array]

[murgatroid99]

I think currently it will be hard to tell whether that actually worked, so it would be a good idea to add something like this in the DNS resolver constructor:

if (GRPC_NODE_USE_ALTERNATIVE_RESOLVER) {
  trace('Using alternative DNS resolver.');
}

[gkampitakis]

the node --env-file was added only on node 20 though right? will it work with the CI running on 14 and 16?

[murgatroid99]

You're right, that probably won't work. So, here's another alternative: add another target that just sets process.env.GRPC_NODE_USE_ALTERNATIVE_RESOLVER = 'false'; and add it to the end of the test series.

[murgatroid99]

Unfortunately, I don't think this quite works because at the top level, the test suites are run in parallel. I think changing this line to run in series should fix it.

[murgatroid99]

OK, this seems to be in a good state now. Thank you for contributing this, and for working with me to get the tests working.

[gkampitakis]

@murgatroid99 Thank you for the patience and all the help to bring it in a good state 🙇

[murgatroid99]

This is now out in version 1.11.0.