gRPC is not directly a Google product, it's donated to the CNCF. Google has use cases where google.rpc.Status is sufficient, but there are a LOT of other companies that have different use cases and requirements. The Proto status can be impractical on Android for instance, where Protos cause large binary bloat and method count.
Also, recall that gRPC uses HTTP/2, which means trailers typically will contain the status. Proxies, logging, and other request processors would have to unpack the proto to use the fields. This makes it hard to use prebuilt tools to monitor the traffic. As an example, consider two approaches to expressing a DEADLINE_EXCEEDED scenario. In this scenario, your monitoring wants to know if the deadline was exceeded due to the server timing out, or because one of the dependent backends of your server timed out. If it was the first, it should alert your monitoring, in the second case, the dependent backend should be alerting. To express this dichotomy, you include either a custom field in status Proto, or a custom header in your gRPC trailing Metadata. Lastly, suppose you have a proxy (like Envoy, or nginx) that can see the responses of your server and fire alerts. In the proto scenario, your proxy (or other alerter) cannot look into the fields, so it has to assume all DEADLINE_EXCEEDED errors are noteworthy, since it cannot inspect the proto. In the trailing Metadata scenario, a lot more tooling can inspect the headers and make a decision. This scenario is a little contrived, but coming back: If we standardized on the Proto, it would exclude some valid use cases, for a proto dependency, and make gRPC not protocol agnostic. Google /can/ decide for all of it's code that Proto is okay, but it cannot dictate it is right for everyone. (what about the gRPC+Thrift users?) On Wednesday, May 22, 2019 at 7:14:15 PM UTC-7, Chris Toomey wrote: > > Sure, but if people are working on a concerted effort to support > google.rpc.Status > <https://cloud.google.com/apis/design/errors#error_model> in a bunch of > grpc language libraries (Java, Go, grpc-web/JS, ...) so that developers > building grpc apps with those languages can use it for richer error > reporting, this effort should be publicized so that developers can take > advantage of it when appropriate. > > If it's good enough for Google Cloud to standardize on, why shouldn't it > be documented for others to standardize on? > > On Wednesday, May 22, 2019 at 11:26:23 AM UTC-7, Penn (Dapeng) Zhang wrote: >> >> The grpc core library io.grpc:grpc-core >> <https://www.google.com/url?q=https%3A%2F%2Fsearch.maven.org%2Fsearch%3Fq%3Da%3Agrpc-core&sa=D&sntz=1&usg=AFQjCNH6o5Hz1JqFnqPZvL66Pp3LqXtu0A> >> does >> not and should not depend on protobuf, so we can not use >> google.rpc.Status >> <https://cloud.google.com/apis/design/errors#error_model> as a >> replacement of io.grpc.Status >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fgrpc%2Fgrpc%2Fblob%2Fmaster%2Fsrc%2Fproto%2Fgrpc%2Fstatus%2Fstatus.proto&sa=D&sntz=1&usg=AFQjCNGETk39EM57QWTtCtv7Z77kVWCxPA> >> at >> the core library level. >> > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/92399e0a-d915-44ab-a216-e404f132bd62%40googlegroups.com.
