Skip to content
This repository has been archived by the owner on Dec 18, 2024. It is now read-only.

Commit

Permalink
doc.protocol: Add gRPC documentation
Browse files Browse the repository at this point in the history
  • Loading branch information
Romain Létendart committed Nov 3, 2022
1 parent 7ee7021 commit bd3b02e
Showing 1 changed file with 52 additions and 0 deletions.
52 changes: 52 additions & 0 deletions doc/protocol/grpc.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
# KUKSA.val gRPC interfaces

## kuksa.val.v1

This interface describes the unified gRPC interface which is split in 2 protobuf definitions:
- [val.proto](../../proto/kuksa/val/v1/val.proto) holding the `VAL` service and associated RPC definitions.
- [types.proto](../../proto/kuksa/val/v1/types.proto) holding the core data types to support VSS needs.

This interface is currently implemented by `kuksa-databroker` and shall soon be implemented by `kuksa-val-server`.

### Error handling (currently)

`Get` and `Set` RPCs rely on `{Get,Set}Response` protobuf message fields to communicate errors i.e.:
```protobuf
repeated DataEntryError errors = 2;
Error error = 3;
```

This means the caller of either `Get` or `Set` needs to check those two fields to decide if there is an error or not.
It is easy to miss for someone who would want to implement `Get` or `Set` and could lead to hidden errors.

`Subscribe` and `GetServerInfo` don't have such error fields in their respective `*Response` protobuf messages.
Instead, errors if any will result in an exception being raised (e.g. `grpc.aio.AioRpcError` in python's case) and that
already comes without further efforts with protoc-generated code.

In some cases though, `Get` and `Set` might still raise `grpc.aio.AioRpcError` e.g. because of network errors.
This means the client needs to handle both `grpc.aio.AioRpcError` errors and response-message-based errors.

What response-message-based errors do provide however are much more detailed errors which is beneficial for the user.

### Error handling (proposal)

In order not to miss errors without sacrificing details in errors' payload, we could:
- Move detailed errors into grpc's `Status.details` which accepts user-defined payloads (see [gRPC error model](https://cloud.google.com/apis/design/errors#error_model))
- Remove `{Get,Set}Response.error(s)?` fields

This way clients would only need to care about `grpc.aio.AioRpcError` that might be raised.

## sdv.databroker.v1

This interface describes the gRPC interface one can use to interact solely with `kuksa-databroker`.
It is not implemented by `kuksa-val-server` and is not planned to be in the future.

- [broker.proto](../../kuksa_databroker/proto/sdv/databroker/v1/broker.proto)
- [types.proto](../../kuksa_databroker/proto/sdv/databroker/v1/types.proto)
- [collector.proto](../../kuksa_databroker/proto/sdv/databroker/v1/collector.proto)

## kuksa.proto (deprecated)

[kuksa.proto](../../kuksa-val-server/protos/kuksa.proto)

This interface is only implemented by `kuksa-val-server` which shall soon implement `kuksa.val.v1` instead.

0 comments on commit bd3b02e

Please sign in to comment.