I don't think this is invalid. Specifically, if we ever detect a txid conflict, we fall back to requiring a full sync.
I guess your point is:
A copied to B
A syncs with C
B syncs with C (no changes detected)
A adds data, syncs with C
B adds data (gets txid conflict) syncs with C, doesn't see the conflict at rev X.
C now has B's txid, but not all of B's data. It has all of A's data.
A adds data
A syncs with C, and sees the txid conflict.
A resets its replica_uid, and starts a full sync with a new uid.
B adds data and syncs with C, but does not detect there is a conflict ever again since it is now the 'owner' of that replica uid.
One option, if we ever detect a txid conflict, we set that replica_uid as 'known bad' and all future syncs from that replica_uid are aborted and told to reset to a full sync before progressing.
That lets us use the smaller txids, and saves a fair amount of bandwidth on send/receive, and a good amount of stored data.
I don't think this is invalid. Specifically, if we ever detect a txid conflict, we fall back to requiring a full sync.
I guess your point is:
A copied to B
A syncs with C
B syncs with C (no changes detected)
A adds data, syncs with C
B adds data (gets txid conflict) syncs with C, doesn't see the conflict at rev X.
C now has B's txid, but not all of B's data. It has all of A's data.
A adds data
A syncs with C, and sees the txid conflict.
A resets its replica_uid, and starts a full sync with a new uid.
B adds data and syncs with C, but does not detect there is a conflict ever again since it is now the 'owner' of that replica uid.
One option, if we ever detect a txid conflict, we set that replica_uid as 'known bad' and all future syncs from that replica_uid are aborted and told to reset to a full sync before progressing.
That lets us use the smaller txids, and saves a fair amount of bandwidth on send/receive, and a good amount of stored data.