Thanks for your very helpful response Carl esp. on the downsides of using google.rpc.Status.
I understand that it cannot *replace* io.grpc.Status and misspoke above when I said that above. What I meant to say and ask for is that the use of google.rpc.Status *as an alternative* for appropriate use cases be documented so that future developers learning gRPC don't see https://grpc.io/docs/guides/error/ and think either 1) they can't return error details, or 2) they have to roll their own ad hoc convention for doing so. More specifically, it'd be super helpful to add discussion of this pseudo-standard alternative, along with the constraints and pros/cons of using it,, and ideally status of gRPC library implementations, to https://grpc.io/docs/guides/error/ . Or if not that page, somewhere else that's linked to or easily discoverable to the new gRPC developer. On Thursday, May 23, 2019 at 8:39:41 AM UTC-7, Carl Mastrangelo wrote: > > 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/df0a6f2a-fa9d-4842-bd89-cf984d4f1a0a%40googlegroups.com.
