gRPC

Two reasons. The wrapper usually runs on the thread driving the connection, and one connection carries many concurrent calls, so it stalls unrelated ones. And it runs inside the call, so its latency is spent out of the deadline the caller already set.

Because the wrapper sits between the handler and the machinery that writes the call's status. Catching the failure and then completing the call normally means OK (0) goes on the wire, and the failure exists only in the server's own log.

Keepalive pings were sent more often than the server tolerates, typically on connections with no active calls. The server counted strikes and, past its limit, sent a GOAWAY carrying ENHANCE_YOUR_CALM and the debug data too_many_pings.

A gRPC method config holds either a retryPolicy, which replays a call after a retryable status with backoff, or a hedgingPolicy, which sends staggered copies without waiting. retryThrottling, a per-server-name token budget, halts both when failures pile up.

gRPC-Web uses no HTTP/2 framing, so no stream-reset frame, connection-closing frame or transport ping tells the client anything. The response ends when its body ends, so a cut response looks complete - except the final trailer frame never arrived.

Client-side balancing costs no extra hop but duplicates the policy in every language and ships only when callers redeploy. A sidecar centralises the policy at the price of a hop, a process per workload, and a new failure domain.

The implementing team owns the file, but it should be published from one place every consumer builds against rather than copied per repository. The cost is a build-time dependency for every consumer: a caller built from generated code reaches a new method only after rebuilding.

No. The two directions of a bidirectional gRPC call are independent: the server may answer after the first message, interleave replies with incoming messages, or wait for the whole sequence. The application protocol decides, not gRPC.

grpc-encoding names the algorithm a sender uses, grpc-accept-encoding lists what it can decode, and each message's Compressed-Flag says whether that message is compressed. A server given an unsupported algorithm fails with UNIMPLEMENTED; a client fails with INTERNAL.

A service's fully qualified name is the proto package, a dot, then the name in the service stanza, and it is case-sensitive. Changing the package line renames the service, so callers built against the old name no longer reach it.

The text variant, application/grpc-web-text, base64-encodes the whole body - frames, payloads and trailer block alike. A client asks for it with Accept: application/grpc-web-text. Its trap is that base64 padding does not line up with frame boundaries.

Metadata rides in a size-bounded field block. The gRPC specification suggests a default limit of 8 KiB on request metadata and trailers, and the HTTP/2 peer advertises its own limit, so an oversized block is rejected by the transport before any handler sees the call.

The client maps the reset's HTTP/2 error code onto a gRPC status. REFUSED_STREAM means the server never processed the call and becomes UNAVAILABLE; CANCEL becomes CANCELLED; most others become INTERNAL, since the call ended abnormally.

A reflection answer describes the instance that produced it. During a rollout the pool holds two builds with different descriptors, and separate calls through a reverse proxy can reach different instances, so two lookups return two versions of the same message.

Nothing in gRPC rebalances an established connection on its own. New workers are picked up only when the caller re-resolves, which happens after a subchannel fails or after the server bounds connection lifetime and closes gracefully.