If a client directly or indirectly tries to subscribe to a cached resource:
subscribe.example.collection
[ 1, 2, 3 ]
And if Resgate is at the same time processing a modifying event for the same resource:
event.example.collection.add
{
"value": 4,
"idx": 3
}
There is a small window of opportunity that can cause the client to get the resource with the event already applied, followed by the same event, causing it to be applied twice for that client:
[ 1, 2, 3, 4, 4 ]
For collections, this will cause the client's version of the resource to become inconsistent with the one stored in Resgate's cache.
Implications
It does not cause inconsistency with model's, as model change events are idempotent.
It only affects specific client connections. Reconnecting will allow the client to re-synchronize back to the correct resource state.
jirenius
commented
3 years ago
Issue
If a client directly or indirectly tries to subscribe to a cached resource:
subscribe.example.collectionAnd if Resgate is at the same time processing a modifying event for the same resource:
event.example.collection.addThere is a small window of opportunity that can cause the client to get the resource with the event already applied, followed by the same event, causing it to be applied twice for that client:
For collections, this will cause the client's version of the resource to become inconsistent with the one stored in Resgate's cache.
Implications
It does not cause inconsistency with model's, as model change events are idempotent. It only affects specific client connections. Reconnecting will allow the client to re-synchronize back to the correct resource state.
There are no security implications.