Deleting a document doesn't seem to actually delete?

I’m working on an app where I’ve written some delete code (calling deleteDocument(id)). But the server seems to not actually delete the document, judging by the cbllog’s:

[DB]: c4doc_put detected server-side branch-switch: “-k0K4AEJN_hqQqO1YLwx84G” 1704-1d916c88aca9c88e6a55d0c882244a20c4c60463 to 1647-210721d78a74277246e6f8b47fce65de; making new branch main & purging old

I have a document replication listener, and after that, I get a pull notification saying that document id has changed.

(edit: I was expecting to get no notifications as I had just deleted the document).

I’m sure I’m doing something wrong. Any hints?

(I’m working on a Mac app, with the latest 2.7 Swift sdk).

Thanks,

Rob.

Deleting a document marks it as deleted. The tombstone has to be replicated to other devices that might have the document, so that they know to delete it too.

On any device that has seen the tombstone, you should not be able to get the deleted document, unless you expressly ask to include tombstoned docs.

Thanks Blake.

In my document replication listener, I check for the deleted flag in the document replication’s document. If it’s not deleted I treat that as a new / updated document.

For my deleted document, I am able to load in the document with no issues when that notification arrives in the listener. I am using the database.document(withId:) method to load in the document to process the change.

Hope that makes sense.

Are you saying that the document is showing up in your replication listener on your client with _deleted flag as true and yet, you are able to access the document body ? That should not be the case. Please share your code snippet and console output

For sanity, I did a test with the 2.7 SDK and it works as expected (Its an iOS app but the SDK is the same)

let token = _pushPullRepl!.addDocumentReplicationListener { (replication) in
                   print("Replication type :: \(replication.isPush ? "Push" : "Pull")")
                   for document in replication.documents {
                       if (document.error == nil) {
                          print("Doc ID :: \(document.id)")
               
                            if (document.flags.contains(.deleted)) {
                               print("Successfully replicated a deleted document")
                               print ("Document is \(self._db?.document(withID: document.id))")
                           }
                       } else {
                           // There was an error
                           
                       }
                   }
               }

I deleted document on server. Delete was pulled down as expected.
Console logs shows the following output

**Replication type :: Pull**

**Doc ID :: user::demo**

**Successfully replicated a deleted document**

**Document is nil**

No, sorry.

I have some old documents that do the following:

  • I call the method to delete the document.
  • that document gets pushed to the server as a delete replication

Push replication, DELETED, details in document: ReplicatedDocument(id: “-WTGwBJmHhfaGeInzJedHgg”, flags: CouchbaseLiteSwift.DocumentFlags(rawValue: 1), error: nil)

  • shortly there after I get a pull replication for that document:

“Datbase replication listener: replication type :: Pull”
Current document replcation: ReplicatedDocument(id: “-WTGwBJmHhfaGeInzJedHgg”, flags: CouchbaseLiteSwift.DocumentFlags(rawValue: 0), error: nil)
processing a database change, new or updated for document id: -WTGwBJmHhfaGeInzJedHgg

I then load in that document from my database, and update my UI with the latest data. In this case because I’ve deleted it in the UI, I end up adding it back.

After more investigation though, it doesn’t happen for all documents, just a few (that are old, from version 1 of the sdk). Newer documents work fine, and behave just as your code shows.

Maybe the server folks here didn’t properly convert to the latest Sync server?

Rob

The message c4doc_put detected server-side branch-switch indicates that some kind of conflict resolution happened on the Sync Gateway side — the revision history received from SG is not an extension of the history it used to have. Are you doing any conflict resolution in SG using the REST API?

Possibly, I’ll ask the server folks. Thanks. :+1: