Deleted documents on server do not get replicated to Couchbase Mobile

[jokill]

My setup is:

Couchbase server

Sync Gateway with bucket shadowing

Couchbase Mobile

When I delete a document on the server bucket, the document is not deleted on the Sync Gateway. It still shows up with /shadow_bucket/_all_docs and I can still view it with /shadow_bucket/key_to_deleted_doc.

How can I make sure the document is also deleted on the shadow bucket?

Many thanks in advance.

[Jens Alfke]

Hm. How are you deleting the document in the original bucket? (It shouldn’t make a difference, but I’m curious.)

Are other changes to documents (creation, updates) being propagated to the Gateway’s shadow bucket correctly?

Try turning on logging for the shadower — launch the Gateway with the extra argument
-log=Shadow+
(or add “,Shadow+” to any existing -log argument.) Then post the log messages that are written right after you delete the original doc.

—Jens

[jokill]

Hi Jens,

Hm. How are you deleting the document in the original bucket? (It shouldn’t make a difference, but I’m curious.) 

With the Node.js API: db.remove(theKey, function(err, result)

Nothing helped so I trashed the sync gateway bucket and created a new one: now it works.

Strange things like this happened before. So I'm curious how stable the system really is…

Thanks for your help, anyway.

Best regards,

Johannes

[Jens Alfke]

On Jul 8, 2014, at 4:25 PM, jokill <j...@masterkitchen.de> wrote:

Nothing helped so I trashed the sync gateway bucket and created a new one: now it works.

Strange things like this happened before. So I'm curious how stable the system really is…

Well, we can’t investigate the problem, now that you’ve deleted the evidence. :( I would have liked to see some logs.

—Jens

[jokill]

Hi Jens

Well, we can’t investigate the problem, now that you’ve deleted the evidence. :( I would have liked to see some logs.

I'm sorry for that. Next time.

Greetings,

Johannes

[Jens Alfke]

I just remembered a likely cause of this, that I think has happened before. You may have a conflict in the document that can’t be deleted. That is, a client of the Sync Gateway may have changed the document at about the same time that the document in the original bucket was changed.

When a document’s in a conflicted state, the gateway determines a ‘default’ or ‘winning’ revision, and that’s the one that will get written back to the shadowed bucket. Live revisions take precedence over deletions, so the document will still exist in the bucket.

An example:

• Doc is created in the Couchbase bucket
• Gateway imports it, assigns it revision 1-abcd
• Client app syncs with the gateway, downloads that revision
• Offline, client app modifies the document creating revision 2-bcde
• Your Couchbase app deletes the document in the bucket
• Gateway notices the deletion, adds a deletion/tombstone revision 2-dbef to the database
• Client app syncs back to the gateway, adding revision 2-bcde to the gateway’s database
• The document in the database is now in conflict. The default revision is 2-bcde which is not a deletion
• Revision 2-bcde gets written back to the original bucket

The moral is to check for conflicts. You have to do so in the Gateway’s database since Couchbase Server itself has no notion of conflicts so there’s no way to tell whether a document in a ‘normal’ bucket has one. Then you can use the Gateway REST API to resolve the conflict and add a merged revision if necessary.

—Jens

[jokill]

Hi Jens,

this can't be the case here, because it is a strict "one way" solution. All changes are handled at the original bucket via a Node.js interface. The mobile devices only pull changes from the server. They never push anything.

Greetings,

Johannes