Description

I'm using grpc-transcode plugin to manage gRPC<=> HTTP, It would be great to convert grpc-status-details-bin in header to HTTP response body in case an error from the upstream.

Decoded grpc-status-details-bin :

Corresponding error model, see https://cloud.google.com/apis/design/errors for more :

package google.rpc;

// The `Status` type defines a logical error model that is suitable for
// different programming environments, including REST APIs and RPC APIs.
message Status {
  // A simple error code that can be easily handled by the client. The
  // actual error code is defined by `google.rpc.Code`.
  int32 code = 1;

  // A developer-facing human-readable error message in English. It should
  // both explain the error and offer an actionable resolution to it.
  string message = 2;

  // Additional error information that the client code can use to handle
  // the error, such as retry info or a help link.
  repeated google.protobuf.Any details = 3;
}

Here are my concerns, quoting from https://www.grpc.io/docs/guides/error/

• Library implementations of the extended error model may not be consistent across languages in terms of requirements for and expectations of the error details payload
• Existing proxies, loggers, and other standard HTTP request processors don’t have visibility into the error details and thus wouldn’t be able to leverage them for monitoring or other purposes
• Additional error detail in the trailers interferes with head-of-line blocking, and will decrease HTTP/2 header compression efficiency due to more frequent cache misses
• Larger error detail payloads may run into protocol limits (like max headers size), effectively losing the original error

Resources:

• Just to give you an idea , similar problem for envoy in the past