Error has inappropriate type with Rich Error Model

[notmedia]

Problem description

In grpc.io there is recomendation to use google rich error model

This model has Status message:

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;
}

So error always has code and message plus optional array of details.

In this package we have sendError method here

You can see that error does not have message field, only code and details.

First I want to ask is it correct and why message value defines into details and then if error.details exists and it is a string it overrides details again?

Second, I want to fix this and send 3 fields correctly, I can create a PR, but first want to pre-approve this approach.
The idea is always send code and message plus optional array of any details.

[murgatroid99]

You did not read the grpc.io page that you linked carefully enough. The "Standard error model" section says

If an error occurs, gRPC returns one of its error status codes instead, with an optional string error message that provides further details about what happened. Error information is available to gRPC clients in all supported languages.

The "error status code" and "optional error message" in that description correspond to the code and details in the Node API.

The "Richer error model" is an extension on top of that that is not directly part of the gRPC protocol. In particular, in that section it says

The protobuf binary encoding of this extra error information is provided as trailing metadata in the response.

Specifically, the grpc-status-details-bin key is used for that information. An API that wants to return a Status message in the response should serialize the protobuf message to binary and include it with that key in the trailing metadata. Issue #184 has more discussion about deserializing that status information on the client, and that refers to a library for doing so: https://github.com/stackpath/node-grpc-error-details.

[notmedia]

And why in Node implementation message called details? I'm trying to figure it out :)
I think that in perfect world all gRPC implementations should have the same API.

Also at grpc.io

This richer error model is already supported in the C++, Go, Java, Python, and Ruby libraries, and at least the grpc-web and Node.js libraries have open issues requesting it.

[murgatroid99]

It looks like the name details comes from the field name in the C core library that the original Node grpc package was built on.

The open issue referenced in that quote is the one I mentioned in my comment, #184.

[notmedia]

Thanks, I'm closing this issue then.