Giters

namely / chief-of-state

gRPC clustered event sourcing tool

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

error details are not propagated from writeside to caller of ProcessCommand

ido-namely opened this issue · comments

commented

Describe the bug
If the implementation of the writesidehandler return a grpc errors with additional details, these details are not forwarded
to the chief of state client. Only the status error code and message are forwarded.

To Reproduce

  1. Configure your write side handler to return a grpc error with details
  2. call ProcessCommand

Expected behavior
ProcessCommand should return the grpc error including the details.

Additional context
This is necessary when writeside handler rejects a command for being invalid and needs to provide details on the violations that were found.

commented

The problem is the default Java grpc client does not use the generated status proto, so when it raises the status exception we lose the details. We do have access to the generated status in interceptors, and we use that proto internally in COS (https://github.com/namely/chief-of-state/blob/master/proto/internal/chief_of_state/v1/internal.proto#L80).

I believe we can accomplish this with custom error handling on the client with an interceptor, then set the outbound status manually instead of throwing the Java status runtime exception.

https://stackoverflow.com/questions/40998199/raising-a-server-error-to-the-client-with-grpc

commented

Yeah as much as I agree we should offer that according to the gRPC doc those error details https://cloud.google.com/apis/design/errors#error_details are supposed to be application as I quote:

Additional error detail types should only be introduced if they can assist application code to handle the errors. If the error information can only be handled by humans, rely on the error message content and let developers handle it manually rather than introducing additional error detail types.

So in my humble opinion we can offer it or leave it to conform to standards

commented

Also let us bear in mind how the various sdk implementation handle them as stated here https://cloud.google.com/apis/design/errors#client_library_mapping. The common ground for all is:

  • the status code
  • the message
commented

I agree that a COS app does not have to have this. Let me try to propagate the details and see what it looks like. IMO if it's easy, we should offer it.