ComponentStatus - to stream, or not to stream

[tiyash-basu-frequenz]

The ComponentStatus enum is used only in the Component message.

The gRPC APIs that use the Component message only use it in simple RPCs (e.g. here). This means that clients can pick up updates to the ComponentStatus field only via polling, instead of streaming. This could lead to instances where clients do not notice the update after long delays, or not at all.

Let's assume that ComponentStatus exists in the streaming data output. Then, as soon as it changes to INACTIVE, we will stop reading data form the component. This will result in no further data in the output stream. This, in turn, means that clients won;t be updated about the ComponentStatus changing to INACTIVE. This means that the ComponentStatus field has to exist in the Component message, where it can always be polled.

This still does not mean that ComponentStatus cannot be streamed, given future context. We are internally deciding to extend this enum to contain more states related to granular read/write abilities on the components. If a client could write to a component, and that component would suddenly becomes read-only, it might be better to stream the ComponentStatus to the client, instead of the client getting an error and then polling the API to find out what's happening.

So the question boils down to if API services should actively notify clients of changes in ComponentStatus, and if yes, then how?

[llucax]

I guess this discussion is broader, at some point (probably not too far in the future) we'll need to be notified of any changes in the component graph. See:

• Refresh the component graph (and pipeline formulas) when it is updated frequenz-sdk-python#1079

So my feeling is we should have a streaming RPC to get notified about any Component, Sensor or Connection that changed too (I didn't check the whole API yet, so maybe there are more entities that could change and we should have a stream-based interface for).

This might be similar to https://github.com/frequenz-floss/frequenz-api-dispatch/ where we have a list RPC to get a snapshot and then a streaming RPC to get updates.

If we unify the approach, we could even have a common client implementation to do this (get a snapshot and subscribe to updates).

FYI @Marenz as you implemented this in dispatch.