No way to differentiate between server-side errors vs client-side errors

[aaijazi]

We want to be able to tell if a particular error was due to a server-side error, or due to the client not being able to connect to the server. There's no good way of doing that right now, since doing grpc.Code(err) will return codes.Unknown for a client error. However, it's possible that the server could also return a codes.Unknown.

[iamqizhao]

You should only feed the error you got from rpc call into grpc.Code instead of arbitrary ones. For now the only case you see codes.Unknown is server application error. Do I miss something here?

[aaijazi]

Two points:

1. I highlighted an example in the linked PR, where I'm seeing an rpcErr even when it's not returned from the server. It's returned by a client/connection issue, which is preventing the RPC from ever reaching the server. I would like to differentiate between these two classes of errors. For example, we have an application that would like to reconnect/retry for client errors, but not necessarily for server issues.
2. It would be much easier to use if we could look at an arbitrary error, and determine "was this error returned by the server?". Is there a downside to provide such a function? It makes the client library implementation cleaner, because we wouldn't have to keep track of which errors could have come from the server vs other issues.

[iamqizhao]

1. If you see rpc error: code = 2 desc = "grpc: the client connection is closing" which is grpc.ErrClientConnClosing, it means your application calls grpc.ClientConn.Close() explicitly when that rpc is in flight. It seems this is an issue of your application. gRPC internal will do reconnect if it sees a connection issue. Applications does not need to do that in most cases. I still do not see a case this could introduce problem unless you feed an arbitrary error to grpc.Code() which should not happen.
2. If you want to bind codes.Unknown with server side error, this seems wrong because grpc internals might also have a case where we need to return codes.Unknown too. I agree that rpcErr is not very satisfying. I am thinking of a way to improve it. But before that I do not hope to go too far (e.g., add more exported API) if possible.

[xiang90]

@iamqizhao

https://github.com/grpc/grpc-go/blob/master/codes/codes.go#L50-L55

From the doc, it says the server might return an unknown error in some cases. So if the application receives an unknown error, there is still no way to know if it is a connection error.

What I want to achieve is to determine if the rpc fails because of client side issues (when the local network is down) or a connection failure (when the server is down).

[iamqizhao]

I will take a look at the unknown case. But regardless, your client should never get a connection error unless you set the connect time out (and then you may get ErrClientConnTimeout error as the connection error) because grpc internal always tries to address connection error by itself. You may get DeadlineExceeded error for sure if you set a deadline for your rpc but the connection cannot be established in time.

[xiang90]

grpc internal always tries to address connection error by itself

So it will retry forever regardless the connection error?