Skip to content
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

Streamline error handling in kuksa.v1 proto #594

Open
SebastianSchildt opened this issue Jul 6, 2023 · 1 comment
Open

Streamline error handling in kuksa.v1 proto #594

SebastianSchildt opened this issue Jul 6, 2023 · 1 comment
Labels
Databroker Issues related to databroker (core) PI13

Comments

@SebastianSchildt
Copy link
Contributor

In case errors occur, we try to give as much details as possible. For errors related tot he VSS model itself, we always try to return eoor information (codes/reasons) in line with VISS (see here: https://www.w3.org/TR/viss2-transport/#status-codes)

We are not always successful with this, as for some calls we return custom errors, other calls lacke them, sometimes we fall back to generic GRPC errors without (being able to) setting the correct error information.

This should be streamlined, so that you can expect errors to be returned in the same way, and where applicable error codes aligned to VISS

Related discussion in Wiki https://github.com/eclipse/kuksa.val/wiki/KUKSA.val-gRPC-interfaces
#586

@erikbosch
Copy link
Contributor

erikbosch commented Jul 7, 2023

I see two parts of this problems. The first is how errors are returned to the actual gRPC-client. There we can affect what is returned in those cases where the RPC reaches the "business logic" on the server side, for example if token validation fails. But then we can have another level of abstraction, and that is what is returned to users of "official KUKSA clients", like the databroker-cli or kuksa-client. It would be possible in the client to match Proto error codes (see https://grpc.github.io/grpc/cpp/md_doc_statuscodes.html) to something else. Like if the response provided by the server cannot be parsed, should we then just show the gRPC error "INTERNAL", or should we on client side try to translate it to for example "406 (Not Acceptable)". Especially if we want to continue to support KUKSA.val Server it would be preferable to have a consistent error handling for both Databroker and Server, so that a client can switch between them. That means that the client always must return a "KUKSA error code" to the caller, either by taking one embedded in the gRPC (or websocket) error message, or if not present by mapping the transport layer error message (gRPC/Websocket) to a reasonable "KUKSA error code". For troubleshooting it is off course good to keep and present the gRPC/websocket error as well.

@lukasmittag lukasmittag added the Databroker Issues related to databroker (core) label Jul 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Databroker Issues related to databroker (core) PI13
Projects
None yet
Development

No branches or pull requests

3 participants