-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: Recreating deleted document can break replication when VDU function is active #1418
Comments
Hello, We are facing a similar issue as the one described by @ondra-novak on the Steps to reproduceLet
Expected behaviorThe user document might be replicated from Current behaviorThe document is not replicated and the number of documents on Environment
This issue is quite impacting for us as it silently breaks replication and can lead to data loss. Thanks in advance for helping us on this bug. Do not hesitate to ask me for more infos if needed. |
This commit handles document creation when the document is not created by replication because of the bug described below. **Bug** A bug exists in CouchDB when replicating a document that where created, replicated, deleted, re-created (with the same ID) and replicated again. We expect CouchDB to create the document on the last replication as it would normally do but it doesn't. Another user already opened an issue on the CouchDB issue tracker. See: apache/couchdb#1418 I have tested it locally and the bug reproduction procedure is available on the issue. To confirm this fix works I am just using `coucharchive` on the last replication.
This commit handles document creation when the document is not created by replication because of the bug described below. **Bug** A bug exists in CouchDB when replicating a document that where created, replicated, deleted, re-created (with the same ID) and replicated again. We expect CouchDB to create the document on the last replication as it would normally do but it doesn't. Another user already opened an issue on the CouchDB issue tracker. See: apache/couchdb#1418 I have tested it locally and the bug reproduction procedure is available on the issue. To confirm this fix works I am just using `coucharchive` on the last replication.
This commit handles document creation when the document is not created by replication because of the bug described below. **Bug** A bug exists in CouchDB when replicating a document that where created, replicated, deleted, re-created (with the same ID) and replicated again. We expect CouchDB to create the document on the last replication as it would normally do but it doesn't. Another user already opened an issue on the CouchDB issue tracker. See: apache/couchdb#1418 I have tested it locally and the bug reproduction procedure is available on the issue. To confirm this fix works I am just using `coucharchive` on the last replication.
This commit handles document creation when the document is not created by replication because of the bug described below. **Bug** A bug exists in CouchDB when replicating a document that where created, replicated, deleted, re-created (with the same ID) and replicated again. We expect CouchDB to create the document on the last replication as it would normally do but it doesn't. Another user already opened an issue on the CouchDB issue tracker. See: apache/couchdb#1418 I have tested it locally and the bug reproduction procedure is available on the issue. To confirm this fix works I am just using `coucharchive` on the last replication.
So I know this was filed a long time ago, but - what a fascinating bug report! I understand what's happening in @ondra-novak 's initial report, but it's not clear to me that @bravier is experiencing the same issue. In Ondra's case the validation failure happens because the replicator skips over the deletion, which means the target sees the old version (before the deletion) and the new version, and their In @bravier 's case there's a replication after every edit, so it's definitely a different situation. I'm wondering if in that situation At a higher level ... I'm concerned a bit about the reliance on the presence of Separately, at some point we blocked the ability to supply the I don't have a great answer about how to proceed here, but figured I should write down a few details that I picked up because I happened to be looking at this part of the codebase for #1957 and @wohali pointed me to this ticket as an interesting edge case. |
This is an interesting edge case indeed! I also experience the bug on CouchDB 2. My understanding is that it happens in this particular case:
|
I have got the same issue as well for the database. Currently, i dont allow to delete but only remarked as "deleted". Haha |
It is possible to recreate (i mean: to update a deleted document with new content which hasn't the flag _deleted set to true) a document without need to specify revision field (_rev). However this behaviour has been changed somehow in CouchDB 2+.
In CouchDB 1.X, one can recreate document with the correct revision. It is also possible to recreate document without the revision and in this case, the CouchDB 1.X uses the document's recent revision. The rest of the operation is similar to updating existing document, including how the VDU (validate_doc_update) is called.
Consider following declaration (formatted to achieve better reading)
In normal operation,
oldDoc
contains old document,newDoc
contains new document. If the document is being created, the function is called witholdDoc == null
. For all other updates the function is called witholdDoc
equal to the body of the document being updated.In
CouchDB 1+
this is also applied for deleted documents, when the document is recreated, regardless on whether it is recreated with _rev or without the oldDoc contains the body of the deleted document.In CouchDB 2+ this is no longer true. When the document is being recreated, oldDoc is always null. This behaviour can break replication in situation, when the replication is not continuous and when the document is deleted and recreated between each replication round.
Expected Behavior
If the document is recreated, the oldDoc of VDU should contain the body of previously deleted document
Current Behavior
If the document is recreated, the oldDoc of VDU is set to null
Possible Solution
The recreating of the document is mistakenly handled as a creation of the new document. It should be handled as an update.
Steps to Reproduce (for bugs)
This bug is dangerous in a one way. There is no way to detect, that the document is being recreated so the creator can create a document which suddenly cannot be replicated. There is also no way how to prevent such situation, because the VDU cannot distinguish between creation and recreation
creation:
recreation:
Context
The main goal of the checking the owner in the VDU is to prevent user to steal a document owned by other user.
Your Environment
The text was updated successfully, but these errors were encountered: