Hi, I've tried to understand the implementation and APIs from KIP-67 and would like to know the possible semantics for read requests from a client perspective. As a developer of a queryable state client, the access semantics I would like to have (I think...) is one where subsequent reads always return the value from the last read or a newer value (if the state store is available). This should be independent of the current system configuration, e.g. re-balancing, failures etc. .
A client-side get(k) can be implemented by starting with a lookup for the instances that store k followed by a retrieve of the value associated with k from the instances returned by the lookup. In the worst case we can always do scatter+gather over all instances. We can start by considering a get(k) under two failure-free cases: a) single instance and b) a system going from one instance to two instances. In case a) the lookup will always return the same instance and the following get will read from a local store. The semantics in this case depends on the local store. For case b) the lookup returns instance A, but in between the lookup and the get, a new instance B is introduced to which k is transferred? Does the state store on A become invalid when the state is re-assigned? Is there another way for the client to detect the change? Best Regards, Mikael
