Closed koblas closed 1 year ago
Hey David, it would be convenient to have just the information under the "debug" field, I agree.
We cannot do that because we want to enable protocol transcoding between Connect and gRCP or gRCP-web. The latter two store error details as a google.rpc.Status message in a grpc-status-details-bin
trailer in binary format. To allow middleboxes without knowledge about the schema to transcode to or from Connect, we have to use binary format as well.
We do provide the JSON representation if we can, but it is optional. Quoting from the protocol spec:
Each detail is an object with "type" and "value" properties and any number of other properties. The "type" field contains the fully-qualified Protobuf message name as a UTF-8 string, and the "value" field contains unpadded, base64-encoded binary Protobuf data. For readability on the wire, server implementations may also serialize the detail to JSON and include the resulting object under the "debug" key. Clients must not depend on data in the "debug" key when deserializing details.
I'm closing this issue because protocol transcoding is an important feature we want to retain.
Everything Timo said is 100% correct. David, some more context on the gRPC protocol may be helpful...
Error details are not formally part of the gRPC protocol specification, despite being important and widely used. Because they were added before the gRFC process existed, there's very little documentation - you have to read through the various implementations to sort out how they work. They're also a little odd - it's the only place where gRPC is irrevocably tied to Protocol Buffers. No matter what codec you use, error details are always sent over the wire as base64-encoded binary protobuf. 🤷🏽♂️
To let proxies, net/http
middleware, and other systems without access to schemas translate the Connect protocol to and from gRPC, we need to send binary on the wire too. This is one of the two main concessions we had to make to maintain parity between the two protocols (the other is reusing gRPC's status codes).
Describe the bug
I was setting up error handling for fields (missing email address in this example). When the error was serialized via JSON the error was not in the details array directly but in a
debug
member of the entry. I was expecting this to be serialized in more top level entry. While I don't have a JSON representation around from when I was working with GRPC-JSON from golang, the code I didn't use the debug member.Note: this comes from
protocol_conect.go
func (d *connectWireDetail) MarshalJSON() ([]byte, error) {
To Reproduce
When the following code is used to build a BadRequest + FieldViolation error message, the result is given in JSON.
Environment (please complete the following information):
connect-go
v1.5.2go
v1.19go.mod
:Additional context
n/a