-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uServices error handling? #2
Comments
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: ***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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'tgoogle.rpc.Status
implicitly included anyway, i.e. a server can return for instanceINVALID_ARGUMENT
(like in this example) even if there is no explicitgoogle.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?The text was updated successfully, but these errors were encountered: