Differences

This shows you the differences between two versions of the page.

--- grpc [2026/07/10 16:49] – created carl
+++ grpc [2026/07/13 19:06] (current) – carl
@@ Line 1: / Line 1: @@
 ====== 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.