Table of Contents
gRPC
Status Codes
Status codes are intentionally vague, to enable automatic processing by code. There are not 5 different flavors of internal errors. This is balance between being precise, and being automatable.
Additionally, status codes intentionally do not indicate if they originated from the client or server.
Cancelled
DEADLINE_EXCEEDED and CANCELLED are both statuses that can appear when a client is no longer interested in a response. There is a race condition however. When the client sends the initial headers, it indicates a timeout (not a deadline) to the server of how long it is willing to wait for the trailers. The client then starts its own timer, which is based on a deadline, after which it will mark the RPC as deadline exceeded. At the same time, the server (a few milliseconds later) sees the timeout, and starts it's own (local) deadline timer. This means there are two timers, one on the client and one on the server, both armed to cancel the RPC. However, there is a race. Since there was a minor delay in the initial RPC headers, the client timer is slightly ahead of the server. When the client cancels the RPC due to a deadline, it needs to incur that same delay in notifying the server. This means that the server's timer will race with the client cancellation, thus making it ambiguous if the RPC is DEADLINE_EXCEEDED, or CANCELLED.
Thus, it's usually better to handle both deadline exceeded and cancelled as the same on the server side, since they are pretty similar. For metrics, the client side is more authoritative than the server.
Changes for 2.0
Some changes I would make to gRPC, if I needn't worry about backwards compatibility.
Statusshould not have the static members for each Code.Statusfactory constructors should have required a String for the reason, rather than leaving it optional. It's too easy to forget.StatusRuntimeExceptionandStatusExceptionshould have been namedStatusExceptionandStatusCheckedException. The SRE version is too long, and by far the more common.- Same with
Status.asRuntimeException(). It's common enough that it deserves a shortname.
