uServices error handling?

[erikbosch]

Out of curiosity, is there a "design pattern" documentation for uServices? I notice that all RPCs return a message containing google.rpc.Status. But isn't google.rpc.Status implicitly included anyway, i.e. a server can return for instance INVALID_ARGUMENT (like in this example) even if there is no explicit google.rpc.Status field in the return message.

Or is it so that as part of uServices/uProtocol that an explicit google.rpc.Status as part of the return message always is required, or at least recommended?

service Engine {
...

  // Request to reset an engine component's life to 100%. After a reset, the
  // remaining life will go back to 100% and the health state of that component
  // will go back to the OK state.
  rpc ResetHealth(ResetHealthRequest) returns (ResetHealthResponse) {
    option (method_id) = 1;
  }
}

...

// Response to reset health request
message ResetHealthResponse {
  // Rpc return status
  google.rpc.Status status = 1;
}

[stevenhartley]

Services can return anything, checkout https://github.com/eclipse-uprotocol/uprotocol-core-api/blob/main/src/main/proto/core/usubscription/v2/usubscription.proto that is also a uService. Steven.

…

On Tue, Oct 24, 2023 at 11:39 AM Erik Jaegervall ***@***.***> wrote: Out of curiosity, is there a "design pattern" documentation for uServices? I notice that all RPCs return a message containing google.rpc.Status. But isn't google.rpc.Status implicitly included anyway, i.e. a server can return for instance INVALID_ARGUMENT (like in this example <https://github.com/grpc/grpc/blob/master/examples/cpp/error_handling/greeter_server.cc#L57>) even if there is no explicit google.rpc.Status field in the return message. Or is it so that as part of uServices/uProtocol that an explicit google.rpc.Status as part of the return message always is required, or at least recommended? service Engine { ... // Request to reset an engine component's life to 100%. After a reset, the // remaining life will go back to 100% and the health state of that component // will go back to the OK state. rpc ResetHealth(ResetHealthRequest) returns (ResetHealthResponse) { option (method_id) = 1; } } ... // Response to reset health request message ResetHealthResponse { // Rpc return status google.rpc.Status status = 1; } — Reply to this email directly, view it on GitHub <#2>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDANOXWQRADZOUTNAZGURTYA7OJXAVCNFSM6AAAAAA6N5AVFCVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE2TSNJUHA3TKMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[stevenhartley]

We have further elaborated about this in https://github.com/eclipse-uprotocol/up-spec/blob/main/basics/error_model.adoc where a service returns the expected google.protobuf.Message when everything is ok (or Void) and if there is a failure, we populate the error in commstatus. More details are in the RPC flows explained in the different language libraries (ex. up-cpp, up-java, up-rust, etc...) with examples.

[stevenhartley]

@halimragab please close (I don't seem to have permission to do so

[erikbosch]

But isn't what you are saying contradicting what we have in this repo.

In https://github.com/COVESA/uservices/blob/main/src/main/proto/vehicle/propulsion/engine/v1/engine_service.proto we have

service Engine {
  ...
  rpc ResetHealth(ResetHealthRequest) returns (ResetHealthResponse) {
    option (uprotocol.method_id) = 1;
  }
}

// Response to reset health request
message ResetHealthResponse {
  // Rpc return status
  google.rpc.Status status = 1;
}

What you are saying above is that ResetHealth only should return ResetHealthResponse " when everything is ok", otherwise populate commstatus.

This is also aligned with the description in https://github.com/eclipse-uprotocol/up-spec/blob/main/basics/error_model.adoc

In case of successful execution of a service operation, a service provider MUST put the operation’s response Protobuf Message into the response UMessage's payload and MUST set its commstatus attribute to value OK.

In case of erroneous execution, a service provider SHOULD put a UStatus Message into the response UMessage's payload and set its commstatus attribute to the same value as the UStatus' code property.

But then I do not understand why you need a google.rpc.Status in the Proto response message. If there is a failure, you will not return ResetHealthResponse, or?

// Response to reset health request
message ResetHealthResponse {
  // Rpc return status
  google.rpc.Status status = 1;
}

[stevenhartley]

I'm glad you noticed that :-). @halimragab we changed this for the uProtocol services and we need to go in and revisit the COVESA uServices as well as mechatronics will not be able to return uStatus anyways (only uCode).

@halimragab do you want me to push the change or will you?