-
Notifications
You must be signed in to change notification settings - Fork 7
Description
What's needed?
After talking a few API client app/library maintainers, it sounds like a challenge to determine if a component is not streaming data due to a component error, or an error internal to the client-side code. While this should be properly handled on the client side, it seems like having a redundant mechanism to confirm if a component is not streaming data would be helpful.
Proposed solution
One solution to achieve some simple redundancy, while exposing helpful information, would be to include a "last-data-sample-seen" timestamp to the component metadata. This could be achieved by extending the following RPC's response with a new field last_heard_from_ts:
| rpc ListComponents(ListComponentsRequest) returns (ListComponentsResponse) { |
Here is the response object which would then be extended:
frequenz-api-microgrid/proto/frequenz/api/microgrid/v1/microgrid.proto
Lines 337 to 341 in f31edd1
| // A message containing a list of components. | |
| // Used as the return type in the RPC `ListComponents`. | |
| message ListComponentsResponse { | |
| repeated frequenz.api.common.v1.microgrid.components.Component components = 1; | |
| } |
Note that the same exercise needs to be repeated for sensors as well.
Use cases
While the proposed solution would address the challenge described above, it could also be helpful in quickly determining health statuses of components that are not streaming data. Again, this could be checked by streaming the component data and not receiving any data sample for a sufficiently long amount of time. But, having a timestamp displayed in the metadata might be more user-friendly.
Alternatives and workarounds
As mentioned earlier, one alternative is to stream component data, and checking how long it goes without having received any data.
Alternatively, this could also be implemented in a client unit.
Additional context
No response