The root cause of this issue, I think, is that the editing action doesnât re-add an item if itâs already deleted. In theory, the now detached item was still successfully modified, itâs just that nobody can see it.
Is this a surprise though? By the last-sync-wins rule, if the last person decides to delete it, the item will get deleted, otherwise weâre basically invalidating the userâs actions, which might create inconveniences too.
When point 3 and 4 happen in reverse, this happens: when the first computer gets connection, changes from the 2nd computer come first and get applied. Then the item gets deleted. This means that changes from the first computer are retrievable in version history.
This is not ideal, but I think itâs better than preventing the deleting from happening at all. Itâs a balance between accuracy and security. When point 3 and 4 are reversed, the current model is more accurate, but it runs the risk of losing some data (still retrievable in version history but you might not realize it). Itâs the choice of âdo I prefer to occasionally [unintentionally delete data] or [fail to delete data]â?
Generating conflict copies is probably the most fail-safe way though.
@Alan I know youâve read this, just posting this as a reference: Dynalist concurrency model
If I understood it correctly, the case youâre raising is different from whatâs being discussed in that post because the order of 3 and 4 are reversed.