XDCR - Failing with reason target has a latest copy

Dears

There were around 23M documents in our couchbase cluster B out of which we have deleted 21M documents.
We loaded fresh copies of these 21M documents in another couchbase cluster A.
Now we enabled XDCR from cluster A to cluster B but looks like no copy of data is happening.
When checking XDCR logs on source cluster which is A we find this interesting lines

2021-08-07T23:06:51.257+02:00 DEBU GOXDCR.XmemNozzle: xmem_dbf3b0199baf892b0d5bfa9cfdb33198/assigned-product/assigned-product_10.121.110.48:11210_1 doc AP:BULK#611429818#49162719 failed source side conflict resolution. source meta=[key=AP:BULK#611429818#49162719; revSeq=1;cas=1628183576094572544;flags=33554432;expiry=0;deletion=false:datatype=3], target meta=[key=AP:BULK#611429818#49162719; revSeq=2;cas=1628360314938916864;flags=33554432;expiry=1628360315;deletion=true:datatype=0]. no need to send

Despite deleting the document from couchbase how is this document key still known and its meta() information still available ? Is it because of the fact that revSeq is higher XDCR is not copying the document to cluster B?

How can this problem be solved?

Regards

When you delete items, tombstones are created:
https://docs.couchbase.com/server/current/learn/buckets-memory-and-storage/storage.html#tombstones

You can tell because the “deletion=true” in the debug statment.

The tombstones actually are winning the conflict resolution. You can see both revSeq and CAS are larger for the tombstones. To solve this, follow the document guide on how to purge the tombstones.