@dmonad Thanks for the reply!
I’m having a little difficulty imaging such a case. I tried to come up with a scenario here - is this such a case?
Imagine three clients A, B, and C:
- A sends change 1.
- B receives change 1 and applies it.
- B then generates change 2 based on change 1. Change 2 is a transaction containing two operations 2a and 2b.
- B sends change 2.
- C receives 2 before it receives 1.
- C is able to apply 2a but not able to apply 2b, and so it applies 2a. This incompletely applies the transaction of 2.
- Later, C receives 1 and is able to apply that. Then, it also can finish applying 2 by applying 2b.
I’m trying to build an intuition of when this partial transaction application might happen. For the phrase “can be applied” above, what does this mean? My understanding of CRDT mechanisms is fairly weak, feel free to refer me to some literature. Does this have to do with data available in the types? Or clocks? If you have seen realistic motivating examples here, that’d be helpful to share, too.
Also, it seems that this may be impossible in a provider setup where all changes are routed through a single node, e.g. y-websocket, where a single node can impose an authoritative ordering on the operation history. Is this a fair assumption? I understand that this depends on a specific topology and would not generalize e.g. to y-webrtc with p2p.
Last, I came across yjs/INTERNALS.md at main · yjs/yjs · GitHub which does describe a transaction as “a set of updates to the Yjs document to be applied on remote peers atomically”. Would you be open to a PR updating this with some caveat example(s) if I’m understanding them correctly?
Thanks!