blackwell-systems commented on issue #6162: URL: https://github.com/apache/couchdb/issues/6162#issuecomment-6132214891
Thanks for looking at this, and agreed: `_revs_limit` 1 and 2 are artificial. I used them to make the short history easy to reproduce. I checked whether it depends on the limit being that low. It doesn't, but it does need mismatched limits: - With the same `_revs_limit` on every database (1000, and also 2, 3, 10 and 100), the two targets never diverged, including documents edited 1,200+ times. - With one replica's limit lower than the others', they diverged every time. At 999 vs 1000 with a 1,000-edit document it reproduces via `_bulk_docs` with `new_edits: false`. Through the replicator with default settings, I've confirmed it at 100 vs 1000. I also tested where the revision is dropped. On a target with a VDU that rejects every write to the doc, re-sending a revision the target already has as a leaf, now with its full history, returns no error and changes nothing, while a new revision to the same doc is rejected as expected. So the re-sent leaf never reaches `validate_doc_update`, which fits the "ignore but consider it a success" branch in `prep_and_validate_replicated_updates`. Without a VDU, the same re-send is merged and `couch_key_tree:stem` / `repair_tree` joins the two roots. The replicator's part is the `_revs_diff` skip in `find_missing`, which re-sends a revision the target already has, this time with its full history. So a minimum `_revs_limit` wouldn't close it, since 999 vs 1000 still triggers it. Also, in my original repro, a design doc in the same `_bulk_docs` request makes a target without a VDU take the same path. Happy to post the 999 vs 1000 repro as curl steps if that's useful. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
