UndoManager: Undoing combination of Y.Map#set and deleting that Y.Map from parent Y.Array results in 1 client with invalid Y.Map about yjs

[francisduvivier]

Note: we also found another woraround
When using { ignoreRemoteMapChanges: true } in the UndoManager constructor, this issue is also not reproducible.

[cacosandon]

I have the same issue. Another workaround is using captureTimeout: 0 so the set + delete are not stacked together.

It's this same issue:
#443

It was resolved, but seems that it's happening again.

[francisduvivier]

I have the same issue. Another workaround is using captureTimeout: 0 so the set + delete are not stacked together.

It's this same issue: #443

It was resolved, but seems that it's happening again.

Issue is slightly different than #443 in the sense that only the second client has the bad map in this bug here

[markcrispo]

I also just hit this issue using XmlFragments and was doing some digging with the debugger before finding this issue.

UndoManager calls redoItem to remake the map and keys. When remaking the Item for 'before change', origin is set to the now-deleted item 'changed content', but parent correctly points to the new, re-created map.

Then the function Item.write serializes the items to sync remote clients, but Item.write only encodes parent if origin is null, so remote clients only see that the 'before change' key has an origin pointing to the deleted map key. As far as I can tell, it looks like remote clients are connecting the recreated key to the deleted map, instead of the recreated map.