Details
-
Bug
-
Resolution: Fixed
-
Critical
-
5.0.0
-
None
-
Triaged
-
Yes
Description
This behavior means that the rev no of the document isn't replicated intra-cluster – or via XDCR. Which has serious implications for XDCR under rev-id conflict resolution.
To repro:
- create document in UI - notice has rev no. 1
- delete - tombstone will have rev no. 2
- create document again in UI - notice has rev no. 3
- bounce server; notice document now has rev no. 1 – i.e. rev no has gone backwards
Is a regression off 4.6 behavior.
Attachments
Issue Links
- relates to
-
MB-27162 Item rev no updated after item is added to hashtable and checkpoint queue
- Closed