1# Status codes and their use in gRPC 2 3gRPC uses a set of well defined status codes as part of the RPC API. All 4RPCs started at a client return a `status` object composed of an integer 5`code` and a string `message`. The server-side can choose the status it 6returns for a given RPC. 7 8The gRPC client and server-side implementations may also generate and 9return `status` on their own when errors happen. Only a subset of 10the pre-defined status codes are generated by the gRPC libraries. This 11allows applications to be sure that any other code it sees was actually 12returned by the application (although it is also possible for the 13server-side to return one of the codes generated by the gRPC libraries). 14 15The following table lists the codes that may be returned by the gRPC 16libraries (on either the client-side or server-side) and summarizes the 17situations in which they are generated. 18 19| Case | Code | Generated at Client or Server | 20| ------------- |:-------------| :-----:| 21| Client Application cancelled the request | CANCELLED | Both | 22| Deadline expires before server returns status | DEADLINE_EXCEEDED | Both | 23| Method not found at server | UNIMPLEMENTED | Server| 24| Server shutting down | UNAVAILABLE | Server| 25| Server side application throws an exception (or does something other than returning a Status code to terminate an RPC) | UNKNOWN | Server| 26| No response received before Deadline expires. This may occur either when the client is unable to send the request to the server or when the server fails to respond in time. | DEADLINE_EXCEEDED | Both| 27| Some data transmitted (e.g., request metadata written to TCP connection) before connection breaks | UNAVAILABLE | Client | 28| Could not decompress, but compression algorithm supported (Client -> Server) | INTERNAL | Server | 29| Could not decompress, but compression algorithm supported (Server -> Client) | INTERNAL | Client | 30| Compression mechanism used by client not supported at server | UNIMPLEMENTED | Server | 31| Server temporarily out of resources (e.g., Flow-control resource limits reached) | RESOURCE_EXHAUSTED | Server| 32| Client does not have enough memory to hold the server response | RESOURCE_EXHAUSTED | Client | 33| Flow-control protocol violation | INTERNAL | Both | 34| Error parsing returned status | UNKNOWN | Client | 35| Incorrect Auth metadata ( Credentials failed to get metadata, Incompatible credentials set on channel and call, Invalid host set in `:authority` metadata, etc.) | UNAUTHENTICATED | Both | 36| Request cardinality violation (method requires exactly one request but client sent some other number of requests) | UNIMPLEMENTED | Server| 37| Response cardinality violation (method requires exactly one response but server sent some other number of responses) | UNIMPLEMENTED | Client| 38| Error parsing response proto | INTERNAL | Client| 39| Error parsing request proto | INTERNAL | Server| 40| Sent or received message was larger than configured limit | RESOURCE_EXHAUSTED | Both | 41| Keepalive watchdog times out | INTERNAL | Both | 42 43The following status codes are never generated by the library: 44- INVALID_ARGUMENT 45- NOT_FOUND 46- ALREADY_EXISTS 47- FAILED_PRECONDITION 48- ABORTED 49- OUT_OF_RANGE 50- DATA_LOSS 51 52Applications that may wish to [retry](https://github.com/grpc/proposal/blob/master/A6-client-retries.md) failed RPCs must decide which status codes on which to retry. As shown in the table above, the gRPC library can generate the same status code for different cases. Server applications can also return those same status codes. Therefore, there is no fixed list of status codes on which it is appropriate to retry in all applications. As a result, individual applications must make their own determination as to which status codes should cause an RPC to be retried. 53