Exposing connection error reasons (ie, TLS failures)

[davidfiala]

I'm curious if there has been any appetite for (or reason against) exposing information on channel connection failures. Specifically in mind are TLS issues wherein the cert of the peer fails checks, such as the cert not being signed by the expected CA.

This information is available in trace logs, but I don't see a way to surface it to the application as of present.

Example of a trace for which I don't see an API way to know about:

GRPC_TRACE=transport,channel GRPC_VERBOSITY=DEBUG ..... ==> | v1.10.6 46191 | transport | dns:X.X.X.X:XXXXX connection failed with error self-signed certificate in certificate chain' (note: self-signed cert error actually can imply that the remote cert simply isn't trusted; error message isn't that important)

I can imagine that many use cases can and need to take action based on these error cases, rather than silent failure from an API perspective.

Thanks for your thoughts.

[murgatroid99]

The client does make an attempt to surface this error information. That was added in #2598. It's possible that there's an issue with that change, or that some errors don't get handled effectively.

[davidfiala]

Apologies if I am missing an obvious path to obtaining this info.

In my mind, I was hoping to expose the underlying error object via getConnectivityState and as a param in watchConnectivityState.

My ideal case was to call new Channel(target, creds, {}) then start a connect via getConnectivityState(true) and wait for success or failure via watchConnectivityState. If there's a TLS error, I'd love to know right then.

Unfortunately I'm having a hard time understanding from the commit you linked to how to use the pickers to get the error. Would you mind giving any additional pointers, please?

Aside from that, assuming I can get the error message: It would be nice as a FR to get the whole error object from here:

grpc-node/packages/grpc-js/src/transport.ts

Line 782 in a4c2106

this.trace('connection failed with error ' + errorMessage);

so that we don't have to attempt string matching against just the .message.

Thank you.

[murgatroid99]

The result of that commit should be that the error text for the underlying error propagates to the error message you get when a request fails. If that doesn't happen for the specific error you're looking for, we can investigate why.

[murgatroid99]

I consider this resolved because TLS errors and other connection errors are included in call error messages.