Crash with attachment after upgrading from CBL 1.4 to 2.6

attachments also get lost when a user does not use the sync feature.

Interesting. That definitely makes database compaction the culprit. And it doesn’t involve conflicted docs (which was a theory of mine) because without sync you have no conflicts.

Is there any chance to tell Couchbase Lite to redownload a specific document? Could I purge the document and then it would get downloaded on its own?

Yes, you can purge the document(s) and then start a pull replication with a set of docIDs containing only the ID(s) of the document(s) that need repair.

I’ll keep staring at the compaction code…

I’ve filed a new issue, CBL-702, since the one filed previously was resolved as a bug in the replicator, whereas your problem doesn’t involve replication.

1 Like

I added a workaround for non-sync users and a workaround for sync users.

Non-sync users

  • Delete file via Android Studio
  • App code recognizes that the file is missing and deletes the pointer to the file in the document
  • Document can be parsed now. Attachment is lost. All good!

Sync users

  • Delete file via Android Studio
  • App code recognizes that the file is missing and sends a web request to update the file via Couchbase Java SDK. The update adds (or updates) a newly added field.
  • Document is downloaded, can be parsed. Attachment is available on disk. All good!

The following did not work for sync users:

  • Delete file via Android Studio for 1st time of document A
  • App code recognizes that the file is missing, purges the document, one-shot pull replicator with document ID is started to pull down the document
  • Document is downloaded, can be parsed. Attachment is available on disk. All good!
  • Delete the same file via Android Studio for 2nd time of document A
  • App code recognizes that the file is missing, purges the document, one-shot pull replicator with document ID is started to pull down the document
  • Document is never downloaded. The whole document is lost forever.

I found this behaviour interesting and wanted to share it.

I did however use the replicator strategy here as I know that this document needs to be there. If I see that this issue happens more than once per user I can update the app code with the first strategy.

That behavior is pretty much expected – once a document is purged, a replicator won’t pull it from the server unless its checkpoint is reset. The first time you recover the doc, it’s a new replicator that starts with an empty checkpoint. The second time, you’d need to reset the checkpoint explicitly.