but the version of the client is not affected by the version of other components so there is no need to change it when the other components change
This is precisely the problem I’m pointing out. There is no “need” to have version numbers on anything. Version numbers, when used, are there to create a contract between the software, its behaviour, and the users.
The contract says “Thing Version A on System B on Date C will behave the same, no matter the system or date, until upgraded to Version X, at which point it will behave differently”.
Back to the “I’m a satellite operator and I need to know how to ignore data with broken timestamps” problem — Either the flowgraph version needs to be sent to the API and stored alongside the observations, or the flowgraph version should be pinned to the client version. I strongly suggest the latter, and suggest more frequent releases of the client to bump the flowgraph version.
Another thread, where broken flowgraphs are being discussed, provides further evidence that versioning and release control of flowgraphs may be a helpful upgrade. (https://community.libre.space/t/observation-14183111-frontiersat-69015-why-is-there-no-data-demodulated)
I really don’t think the solution here is “different container” and “more dependency version sharding”.