Grpc-node: Improve `Error: 14 UNAVAILABLE` Error Message

[amiller-gh]

Is your feature request related to a problem? Please describe.

This connection failure error message can be more verbose to provide assistance to users of software using grpc-js.

Describe the solution you'd like

I could have saved a good chunk of time if this error message had been more helpful! Something like: Error: 14 UNAVAIlABLE. Unable to connect to localhost:8080

Describe alternatives you've considered

n/a

Additional context

I spent a half hour "debugging" what I thought was an issue with grpc-js, but was in fact my own stupidity!

I quickly wrote up a test file for a firebase function I was putting together for a personal project. Since the project is early stages, and I'm going for quick-and-dirty here, I was planning to run this operation on my production database. However, when I ran the script, firebase-admin would hang, then fail with a relatively cryptic Error: 14 UNAVAILABLE message.

What happened? I had forgotten that I copy pasted a .env file from another project in to here, which had a FIRESTORE_EMULATOR_HOST=localhost:8080 line present! Instead of realizing this quickly and moving on with my life, I instead went down a rabbit hole of other issues (there are many...) trying to find why the gprc connection could be failing. It eventually took me setting a breakpoint in grpc-js's load balancer to see it was attempting to connect to localhost!

By telling users what the address is for the failed connection you can easily help users who may fall in to this (relatively easy to encounter!) trap.

[murgatroid99]

This is a fair point. The error messages were originally written with the assumption that the person who saw them would have the context to know what backend the client was trying to connect to, but I can see how it would get abstracted so that that assumption is no longer accurate.

[murgatroid99]

Unfortunately, implementing this is actually going to be a little tricky; the current architecture of the library doesn't support it very well. Currently, those error messages are coming from the load balancing component, which doesn't even know about the target address. Something will have to change to either plumb that information down or modify the error messages in a different layer.

When debugging a problem like this, another good source of the information you were looking for is the trace logging output. All of the tracers can be enabled by setting the environment variables GRPC_TRACE=all and GRPC_VERBOSITY=DEBUG. That would help a situation like this by showing that the resolver is resolving the address dns:localhost:8080 and that the subchannels are trying to connect to 127.0.0.1:8080 and/or [::1]:8080.