You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tl;dr this works as expected. If you want to keep result consistent eg. for the sake of deterministic testing, you should create document with and explicit ID using Y.YDoc(client_id=X).
Longer explanation
The series of updates we're receiving in this scenario - concerning the ysource shared text type is basically:
Create a document with randomised identifier X and put character "a" at the beginning.
Concurrently to pt.1 at document with ID 845456925 insert character "a" at the beginning.
After pt.2 (but still concurrently to pt.1) at the document with ID 3709507946 insert character "b" after character "a" inserted by 845456925.
Serialise updates from pt.2 and pt.3. and apply them to document with ID X from pt.1.
The consistent part is that points 2. and 3. generate a string "ab" that's supposed to be inserted at the beginning of a ysource... however the actual position of a second "a" character is not set in stone, as we have concurrent operation of inserting character "a" at the same position by a different document.
In this case the conflict resolution algorithm will use document IDs to determine which piece of text ("ab" or "a") to insert first and which should be inserted second. Eg. if our document from pt.1 was generated with ID < 3709507946 (pt.3) the result will be "aba", but if its generated ID was higher, then the result will be "aab".
This means that depending on the run, the randomly generated ID can affect the order of operations. If that ID was static (not generated) the order would stay the same.
Using
y-py==0.4.3
, running the following script sometimes prints"aba"
, sometimes"aab"
:The text was updated successfully, but these errors were encountered: