search

grpc / grpc-node

gRPC for Node.js
https://grpc.io
Apache License 2.0
4.47k stars 647 forks source link

Exposing connection error reasons (ie, TLS failures) #2757

Open davidfiala opened 4 months ago

davidfiala commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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: https://github.com/grpc/grpc-node/blob/a4c2106e63064070f3b9e580b2d1c74b0a9503a4/packages/grpc-js/src/transport.ts#L782 so that we don't have to attempt string matching against just the .message.

Thank you.

murgatroid99 commented 4 months ago

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.