Add support for the detailed error model #22
Conversation
Motivation: A common extension to gRPC is a the detailed error model. While not a standard gRPC feature it is widely used. The standard error model only allows for a status code and message to be propagated to the client. The detailed error model allows users to use a common set of structured errors and send them to the client in metadata. The model uses the 'google.rpc.Status' protobuf message to describe the error and any error details. Modifications: - Update the fetch and generate protobuf scripts to get and build the relevant standard protobuf messages. - Add `ErrorDetails` which is a container for common error types. Each of the error types maps to one a standard error detail from the detailed error model. - Add a `GoogleRPCStatus` error which maps to the 'google.rpc.Status' protobuf. This also conforms to `RPCErrorConvertible` so gRPC will automaticlly turn it into an appropriate status and metadata. - Add a helper for unpacking the `GoogleRPCStatus` from an `RPCError`. Result: Support for the detailed error mode.
| /// > the serialized bytes of a "google.protobuf.Any" protocol buffers message. The content of which | ||
| /// > is a "google.rpc.Status" protocol buffers message containing the status code, message, and | ||
| /// > details. | ||
| public struct GoogleRPCStatus: Error { |
There was a problem hiding this comment.
Why not GoogleRPCError? We refer to it as an error, conforms to Error, we compare it to RPCError, and it wraps an RPCError.Code and [ErrorDetails].
There was a problem hiding this comment.
Naming this type is annoying... I picked GoogleRPCStatus because it's effectively a "google.rpc.Status".
Other implementations which support this use the generated proto directly so also call it similarly (depends a bit on the language and how they generate proto messages). I elected not do that for a number of reasons; naming, retroactive conformance to RPCErrorConvertible, user experience etc.
The other idea I had for naming it was DetailedRPCError.
There was a problem hiding this comment.
I see. Personally, I think DetailedRPCError fits better. But I also understand wanting to match google.rpc.Status. So I'll leave it up to you, I'm not convinced either way.
There was a problem hiding this comment.
I think there's a lot of benefit to giving it a name thats similar to other implementations especially as this isn't a gRPC feature, it's a widely used convention built on top of gRPC.
If this was a custom grpc-swift thing then I'd definitely prefer a name like DetailedRPCError.
| /// > the serialized bytes of a "google.protobuf.Any" protocol buffers message. The content of which | ||
| /// > is a "google.rpc.Status" protocol buffers message containing the status code, message, and | ||
| /// > details. | ||
| public struct GoogleRPCStatus: Error { |
There was a problem hiding this comment.
Naming this type is annoying... I picked GoogleRPCStatus because it's effectively a "google.rpc.Status".
Other implementations which support this use the generated proto directly so also call it similarly (depends a bit on the language and how they generate proto messages). I elected not do that for a number of reasons; naming, retroactive conformance to RPCErrorConvertible, user experience etc.
The other idea I had for naming it was DetailedRPCError.
Co-authored-by: Gus Cairo <[email protected]>
Motivation:
A common extension to gRPC is a the detailed error model. While not a
standard gRPC feature it is widely used. The standard error model only
allows for a status code and message to be propagated to the client. The
detailed error model allows users to use a common set of structured
errors and send them to the client in metadata. The model uses the
'google.rpc.Status' protobuf message to describe the error and any error
details.
Modifications:
relevant standard protobuf messages.
ErrorDetailswhich is a container for common error types. Eachof the error types maps to one a standard error detail from the
detailed error model.
GoogleRPCStatuserror which maps to the 'google.rpc.Status'protobuf. This also conforms to
RPCErrorConvertibleso gRPC willautomaticlly turn it into an appropriate status and metadata.
GoogleRPCStatusfrom anRPCError.Result:
Support for the detailed error mode.