What is a better way to return a Grpc validation error

Question

I would like to know if there is a pattern for field validation in grpc services.

I know that RpcException has metadata trailers property and that I can add additional information about my errors.

My question is: There is a pattern to be followed? If not, Which of the examples below would be more in line with the expected.

Example 1:

Metadata trailers = new Metadata();
trailers.Add("Name", "is required");
trailers.Add("Age", "is required");
trailers.Add("Age", "must be over 21");
throw new RpcException(new Status(StatusCode.InvalidArgument, "Invalid Argument"), trailers, "One or more errors");

Example 2:

Metadata trailers = new Metadata();
trailers.Add("errors", @"{""Name"":[""Is required""],""Age"":[""Is required"",""must be over 21""]}");
throw new RpcException(new Status(StatusCode.InvalidArgument, "Invalid Argument"), trailers, "One or more errors");

I would like to take this response and convert it to a json using the RFC 7807 specification when needed

score 4 · Answer 1 · answered Aug 04 '20 at 15:08

I am not familiar with the C# API but I can speak a bit about the gRPC API and maybe it can help you with your C# implementation.

gRPC error model The error model is logically defined by google.rpc.Status, an instance of which is returned to the client when an API error occurs. The following code snippet shows the overall design of the error model, which is returned when something goes wrong:

package google.rpc;

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 delay or any business possible errors
  repeated google.protobuf.Any details = 3;

}

You should use the details field to pass extra information to the error. For example for the InvalidArgument you should pass the BadRequest object with Field violations

Something like (Golang code, hope it makes some sense for you)

st := status.New(codes.InvalidArgument, "invalid username")
v := &BadRequest_FieldViolation{
    Field: "username",
    Description: "The username must only contain alphanumeric characters",
}
br := &BadRequest{}
br.FieldViolations = append(br.FieldViolations, v)
st, _ := st.WithDetails(br)

Here is the list of object that is provided by gRPC which you can use as the error details if any of those fits your scenario you can always create your own.

It is a good practice to return in the details field something related to the business. Like a known error code. This way your client would be able to respond to the issue.

errorDetail := &BusinessError{
  ErrorCode: CODE,
  ErrorMessage: "Failed to filter hotel rooms",
}
st := status.New(codes.Internal, "Something went wrong :( ")
st, _ = st.WithDetails(errorDetail)

What is a better way to return a Grpc validation error

1 Answers1