DOC-12484 XDCR Conflict Logging feature

[rao-shwe]

DOC-12484

Link to the preview doc: https://preview.docs-test.couchbase.com/DOC-12484/server/current/learn/clusters-and-availability/xdcr-conflict-logging-feature.html

• Get login credentials from here.

Preview pages:

• XDCR Conflict Logging
• Viewing Conflict Logs.
• Replication Settings for XDCR Conflict Logging and Replication Settings for XDCR Conflict Logging
• Added conflictLogging in the Curl syntax and explained briefly about conflictLogging in the paragraphs that follow.
• Updated for ECCV Edit a Bucket.
• Added the "NOTE: XDCR Conflict Logging can be enabled only in the Edit a Bucket mode." in Create a Bucket.
• conflictLogging entry in List of Advanced Settings.

DON'T review the following files: The following are 7.6.6 release docs which were missing in the release/8.0 branch. So I added them again.

• xdcr-active-active-sgw.adoc
• xdcr-conflict-resolution.adoc
• xdcr-enable-crossclusterversioning.adoc
• The section [Create an XDCR Replication with mobile=Active](Create an XDCR Replication with mobile=Active).
• Creating and Editing Buckets.

[sumukhbhat2701]

Some review feedback which hold true for all pages:

1. For this feature specifically, we need to use the term "true conflicts" more than just mentioning "conflicts". That means we need to first define what a true conflict is and set the expectation.
2. There should be a warning that this feature is best effort (and that true conflicts is assumed to be very low). Everything that's in this slide - https://couchbase.slack.com/archives/C0963TSUU0N/p1752763776316649.
3. The setting is quite complex to understand just from textual description. An example will do a lot of help to someone new reading this.
4. There should be a mention that on every true conflict detected, XDCR will log 3 documents to the conflict collection - CRD (Conflict record document - contains metadata of detected true conflict), source document in conflict & target document in conflict. It should be mentioned that the CRD will contain the document IDs of source and target documents logged. Maybe an example of source and target document IDs in CRD.
5. Continuation of (3), I think there should be some examples on how to make use of the detected and logged conflicts. Eg: Use SDK, N1QL, range scan, eventing etc.
6. There should be a mention that the logged documents will not be replicated by XDCR if conflict collection is a source collection of any XDCR.

[sumukhbhat2701]

I think I missed one of the pages from reviewing, so if somethings are already done from last comment, please ignore.

[rao-shwe]

@sumukhbhat2701

I've implemented most of your review inputs and closed the comments.

[rao-shwe]

@sumukhbhat2701

Points 1 and 2 are fixed.
Point 3: Already has examples and descriptions. Not okay to repeat the same content in multiple locations. So I've added a link to examples wherever necessary.
Point 4, 5, and 6: Already exists.

Edit: All fixed in draft-2.

Some review feedback which hold true for all pages:

1. For this feature specifically, we need to use the term "true conflicts" more than just mentioning "conflicts". That means we need to first define what a true conflict is and set the expectation.
2. There should be a warning that this feature is best effort (and that true conflicts is assumed to be very low). Everything that's in this slide - https://couchbase.slack.com/archives/C0963TSUU0N/p1752763776316649.
3. The setting is quite complex to understand just from textual description. An example will do a lot of help to someone new reading this.
4. There should be a mention that on every true conflict detected, XDCR will log 3 documents to the conflict collection - CRD (Conflict record document - contains metadata of detected true conflict), source document in conflict & target document in conflict. It should be mentioned that the CRD will contain the document IDs of source and target documents logged. Maybe an example of source and target document IDs in CRD.
5. Continuation of (3), I think there should be some examples on how to make use of the detected and logged conflicts. Eg: Use SDK, N1QL, range scan, eventing etc. @hyunjuV I think you had a document prepared for this, was that for public docs?
6. There should be a mention that the logged documents will not be replicated by XDCR if conflict collection is a source collection of any XDCR.

[hyunjuV]

• If you are using Eventing Service functions that update documents in the XDCR replicated buckets, you must take care that the deployed Eventing functions do not cause XDCR to ping-pong and never stop replicating.

[hyunjuV]

If you are using Eventing functions that update the documents in the XDCR replicated buckets (also referred to as Eventing source bucket mutations), ensure that the deployed functions behave as desired in the replication environment. Within a bi-directional, active-active XDCR environment, the deployed Eventing functions can cause XDCR to ping-pong and never stop replicating if you do not include logic to prevent the infinite loop. In general, for active-active, avoid redundant updates with appropriate logic within the Eventing functions. See XDCR Active-Active and Eventing for more information.

Note for @rao-shwe :
Fortune Ikechi is working on DOC-13300, which will add a page called "XDCR Active-Active and Eventing" in 7.6.x documentation. One of the changes for that work is to update this note in lines 25-26.