Mutating a document with an attachment on over CBL causes the attachment to be deleted from the bucket
Description
Couchbase Lite 3.0.0 and 2.8.6 (and possibly versions below) have a bug where an attachment revpos on a stub is always the document revision. This means that Sync Gateway receives the wrong revpos for a document attachment when the document is mutated which causes SGW to remove it from the bucket, as the old attachment cannot be found and therefore is assumed to be an obsolete attachment.
Reproduction steps using CBL
Create a document with an attachment on it
Start a continuous replication to the sync gateway
When that document has replicated, modify it on CBL by adding a key
Wait for that to replicate to the sync gateway
Check bucket that the attachment has disappeared
Sync Gateways pathing that is causing this
The version is being added when the initial document with the attachment is being created. This is done in storeAttachment
The next mutation of the document causes SGW to go in to the stub handling code in storeAttachment. A parent attachment is successfully retrieved, but because the revpos is not lower than the first revision, the parent attachment does not replace the attachment data causing the attachment version (v2) to be lost (and the revpos).
When the rev processing is done in handleRev then processRev, the leaf attachments cannot be found in getAttachmentIDsForLeafRevisions since the attachment is treated as a v1 attachment (since the attachment is lost), meaning it is not found. This causes no attachments to be found, so therefore the obsolete attachment handling thinks it is an attachment no longer attached to the document causing the attachment to be removed from the bucket.
What needs to be done
An incorrect revpos sent by CBL that is caused by this bug needs to be handled gracefully by treating the attachment as valid and, most importantly, not deleting the attachment from the bucket.
Attachments
1
Activity
Show:
CB robot June 13, 2022 at 4:30 PM
Build sync_gateway-3.1.0-163 contains sync_gateway commit aca3ecd with commit message: : Forward port : Do not evaluate revpos during storeAttachments (#5563)
isaac.lambat May 26, 2022 at 4:49 PM
Edited
Logs with keys filtered:
Relevant logs containing payloads Revision 1
Revision 2
Fixed
Pinned fields
Click on the next to a field label to start pinning.
Couchbase Lite 3.0.0 and 2.8.6 (and possibly versions below) have a bug where an attachment
revposon a stub is always the document revision. This means that Sync Gateway receives the wrongrevposfor a document attachment when the document is mutated which causes SGW to remove it from the bucket, as the old attachment cannot be found and therefore is assumed to be an obsolete attachment.Reproduction steps using CBL
Create a document with an attachment on it
Start a continuous replication to the sync gateway
When that document has replicated, modify it on CBL by adding a key
Wait for that to replicate to the sync gateway
Check bucket that the attachment has disappeared
Sync Gateways pathing that is causing this
The version is being added when the initial document with the attachment is being created. This is done in
storeAttachmentThe next mutation of the document causes SGW to go in to the stub handling code in
storeAttachment. A parent attachment is successfully retrieved, but because therevposis not lower than the first revision, the parent attachment does not replace the attachment data causing the attachment version (v2) to be lost (and the revpos).When the rev processing is done in
handleRevthenprocessRev, the leaf attachments cannot be found ingetAttachmentIDsForLeafRevisionssince the attachment is treated as a v1 attachment (since the attachment is lost), meaning it is not found. This causes no attachments to be found, so therefore the obsolete attachment handling thinks it is an attachment no longer attached to the document causing the attachment to be removed from the bucket.What needs to be done
An incorrect revpos sent by CBL that is caused by this bug needs to be handled gracefully by treating the attachment as valid and, most importantly, not deleting the attachment from the bucket.