saveDocument() decodeTree reading count error

[philmitchell]

I’m seeing saveDocument() errors in production logs:

Code=5 "RawRevision decodeTree reading count error"

CouchbaseLite 3.1.4
iOS 17.2.1

Any help interpreting this error would be appreciated!

[jianminzhao]

Indicating error in binary layout. Is it an old database, or how old is the database?

[philmitchell]

According to analytics, this customer was first seen two years ago. It’s not impossible the db is older than that, but that’s all the info I have.

[jianminzhao]

It could be another reason. There was a bug before 3.0.3, that may cause the Rev tree to grow to more than uint16_max (65535) revisions because of not pruning properly.

[philmitchell]

I guess the question is what to do? It appears that this customer is no longer able to save anything into the db, which makes my app unusable.

[jianminzhao]

If it’s indeed the cause, a possible way to fix it is, get the current revision from the current document, purge this doc, then, create a new doc with that revision.

[philmitchell]

How would I know if it is this rev tree bug?

I don’t see any API to get the “current revision” from a document, but I do have the swift object that is the source of the doc.

Would it be a reasonable strategy in any case where saveDocument() fails to:

1. Purge the doc
2. Re-create it from swift object, keeping same id

Would that have implications for syncing (not currently doing, but plan to)?

[jianminzhao]

FYI, a related issue:

Corrupt Revision Data error when saving documents

SDK: Couchbase Lite C Version: 3.0.2 OS: iOS & Android Error: kCBLErrorCorruptRevisionData This error has only been observed through error reports from user devices, and I have not been able to replicate it. It seems that saving a document can sometimes corrupt it, since after the first time this error has been returned when saving a document, subsequent attempts to save the document always fail with the same error. The document can still be purged, though. There are also crashes in CBLDat…

[jianminzhao]

Is the docID critical? If not, I would use a new docID.
If you must use the same docID, the replicator will treat it as a conflict, and you can resolve it in favor of the local revision.

[philmitchell]

Ok, I will adopt the purge and replace strategy. It would be awkward for us to change the docID, so we’ll have to include that as part of our replication strategy.

Thanks for your help, JianMin!