gRPC defines a rich set of status codes for communicating error semantics between services. Rich error details via google.rpc.Status embed structured protobuf messages, while interceptors enable centralized error handling. Understanding retryable vs non-retryable errors is essential for resilient gRPC services.
0 / 5 completed
1 / 5
A gRPC server returns status code UNAVAILABLE. Which client-side pattern is most appropriate for handling this?
gRPC UNAVAILABLE indicates a transient server-side issue (e.g., overload, restart). The recommended pattern is exponential backoff with jitter — retrying after increasing delays with randomization to prevent thundering herd. gRPC status codes like UNAVAILABLE and RESOURCE_EXHAUSTED are generally retryable.
2 / 5
What information can a gRPC server include beyond the status code to provide more detail about an error?
gRPC supports rich error details via the google.rpc.Status proto, which can embed typed protobuf messages in its details field. Common detail types include BadRequest (field violations), RetryInfo (suggested retry delay), and ErrorInfo (error domain and metadata).
3 / 5
A developer implements a gRPC interceptor. In which scenario would they use an interceptor for error handling?
gRPC interceptors (middleware) are ideal for cross-cutting error handling concerns: logging all errors centrally, translating internal errors to gRPC status codes, adding retry logic, or injecting error metadata. Client-side interceptors catch errors before they reach the caller; server-side interceptors catch errors before they're sent to clients.
4 / 5
Which gRPC status code should a server return when the client sends a request with an invalid field value?
INVALID_ARGUMENT indicates that the client sent data that violates API constraints (e.g., a negative age, an invalid email format). FAILED_PRECONDITION is for correct arguments applied to wrong state (e.g., deleting a non-empty directory). NOT_FOUND is for missing resources, and INTERNAL is for server-side bugs.
5 / 5
A gRPC client sets a deadline on an RPC call. What happens when the deadline is exceeded on the server side?
When a gRPC deadline expires, the server's context is cancelled. Well-behaved gRPC servers check ctx.Done() or ctx.Err() during long operations and abort early when cancelled. This prevents wasted computation on responses the client will never receive. The client receives DEADLINE_EXCEEDED status.