Grpc-go: Are status details always proto?

[akshayjshah]

As part of an internal project, I'm looking at using gRPC with non-standard codecs. Some of the legacy software that would interoperate with this gRPC code can't use the open-source gRPC client libraries, so we'd need to write simple clients for unary RPCs on top of an off-the-shelf HTTP/2 client. Most of the resulting work is straightforward, but I'm not sure how to handle error details properly.

From what I can see, the data supporting the Status.Details and Status.WithDetails APIs are written to and read from the wire as a base64-encoded proto blob, following the "Binary Headers" portion of the HTTP/2 gRPC protocol (for now, pending the proposal to negotiate non-base64-encoded binary metadata).

Do you intend this data to always be proto, even if the request and response of the RPC are using a different codec? If so, is this part of the protocol or an implementation detail? If the former, should this be documented in the protocol spec?

For reference, I'm looking at the grpc-go code on master. This portion of the code doesn't seem to have changed from the 0.15.x branch.

[dfawley]

@akshayjshah,

This issue has come up a few times in the grpc team. C/C++, Java, and Go all treat the status details slightly differently based upon our interpretations of the design. Unfortunately, no gRFC was published for this feature (IIUC it was proposed before the gRFC process existed), and it was never incorporated into the main docs, either. We have an AI to work out the differences and decide on a path forward, hopefully in this quarter.

/cc @ejona86 @markdroth

[akshayjshah]

Thanks for the info, Doug. Will the discussion for this happen in an open venue (e.g., a Github issue), or is this something that'll be Google-internal?

[ejona86]

I was going to write something up that just documents the three language's behavior. I had expected that to be internal, simply because it is sort of a "cliff notes." Then I thought there would be an in-person meeting between the three languages and one or two others involved with the design and we'd figure out where to go from here. We could then make the design direction public and the public could comment.

@akshayjshah, note that for your internal codebase I'd recommend just relying on grpc-status and grpc-message HTTP headers. The benefit of the details is really the repeated Any.

[akshayjshah]

A spec describing how the different implementations behave would be nice, especially if it gives some prescriptive advice for third-party implementations.

I'd recommend just relying on grpc-status and grpc-message HTTP headers. The benefit of the details is really the repeated Any.

Internally, it's (unfortunately) not viable for us to rely solely on the grpc-status and grpc-message headers. Our clients will be communicating with servers using a variety of codecs; a number of those servers use the standard HTTP/2+proto setup, and clients will be significantly handicapped if they can't access the structured error data (e.g., the server's recommended retry policy).

[ejona86]

@akshayjshah, ah, I think I understand now. It sounds like you're coming at this from the perspective of API/implementation design because you have your own implementation; not just limited interop. Yes, the output of the conversation will be a definition of what the details means/how it is encoded when. Right now, between the three languages, we have every possible interpretation.

[akshayjshah]

Any updates on this?

[yang-g]

FWIW I sent out this PR a while back trying to get it mentioned in the
spec. https://github.com/grpc/grpc/pull/12825

That being said, I think nothing stops you to send something custom if you
control both client and server.

On Fri, Dec 7, 2018 at 10:02 AM Akshay Shah [e-mail]
wrote:

Any updates on this?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/grpc/grpc-go/issues/2329#issuecomment-445315105, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJp0CvKVmcoVaWIMR_uylaHAoAURuMSyks5u2q1GgaJpZM4W3pHM
.

[ejona86]

This is still not resolved. I would still avoid using grpc-status-details-bin with something other than google.rpc.Status

[akshayjshah]

Are you open to a PR that (optionally) disables the checks that prevent us from writing to grpc-prefixed headers? I understand that there are a lot of interoperability concerns between the different gRPC implementations that need to be worked out, but it'd be nice to have an escape hatch available.

[dfawley]

Sorry, but no. Even if you were to write them, we would/may overwrite them.

Can you use custom trailers instead of grpc-status-details-bin, since you aren't able to use protos on all your platforms?

[akshayjshah]

Sorry for the long silence! No worries if you don't want to make any code changes. Is the documentation for the first-party implementations' behavior ready yet? Guidance for third-party implementations would be nice too.

[dfawley]

@akshayjshah - all I know about is the PR by @yang-g, which is still pending. This issue comes up from time to time, but it has not been prioritized.

[stale[bot]]

This issue is labeled as requiring an update from the reporter, and no update has been received after 7 days. If no update is provided in the next 7 days, this issue will be automatically closed.

[dfawley]

Since this is really just a documentation issue against the grpc/grpc repo, I filed https://github.com/grpc/grpc/issues/24007 to track. Closing this.

[akshayjshah]

Thanks, Doug!