400 Invalid Attachment Warning / Error in Pull Replication

[David Quon]

We were previously using iOS CBL 1.0.3.1 and recently upgraded to iOS CBL 1.1.1.  Now with certain documents with attachments we started seeing errors like this which stop the replication.  We are running CouchDB version 1.6.1 for our couch server.

2015-10-24 11:21:20.188 AppName[6574:1993505] WARNING: CBL_Puller[https://username:*****@hostname:6984/database] failed to write {namespace/doc_id #198-b707c081c57791deb57a366aee25c141}: status=491

2015-10-24 11:21:20.189 AppName[6574:1993505] Sync: CBL_Puller[https://username:*****@hostname:6984/database] Progress: set error = 400 Invalid attachment

2015-10-24 11:21:20.190 AppName[6574:1993505] Sync: CBL_Puller[https://username:*****@hostname:6984/database] STOPPING...

Now if you query the CouchDB for `namespace/doc_id` I get:

"_id":"namespace/doc_id","_rev":"366-8fc5ffd358688535b06788b5872793bc”,

If I query CouchDB for `namespace/doc_id` with `?revs_info=true` I get back only 10 revisions as it was configured.

So why is CBL complaining about problems with `kCBLStatusBadAttachment` for revisions like 75-100 revisions prior to the latest?  Also when using CBL 1.0.3.1 with the same exact database this issue doesn't occur and everything replicates as expected.  Any suggestions of how to solve this problem would be greatly appreciated as so far none of the workarounds I've tried have yielded a solution.  Thanks.

[Jens Alfke]

A lot of the attachment handling code was changed in version 1.1. There were one or two regressions with inserting replicated attachments, but I thought they’d been fixed. Let’s see…

#802 is exactly like what you’re describing, but it was fixed in 1.1.1.

#843 is the only other similar fix; it’s not in 1.1.1, but it doesn’t look like the same symptom as what you’re describing.

So why is CBL complaining about problems with `kCBLStatusBadAttachment` for revisions like 75-100 revisions prior to the latest?

Yeah, that is strange. That revision must be in the _changes feed on the server, since that’s where the puller finds out what to download.

Can you reproduce this with an initially-empty local database? Or does it only occur if the app had previously synced?

Would it be possible to use a build of the current master branch and try to reproduce the problem? If it doesn’t show up in master, that would help narrow down the problem.

In either case, please file an issue on Github so we can track this.

—Jens

[David Quon]

Yeah I had looked at those issues you referenced but I thought they were both fixed in 1.1.1.  It looked like #843 got fixed in 1.1.1 with commit https://github.com/couchbase/couchbase-lite-ios/commit/9e0cb4dfec67b1f01a2b35f1fd4b0d1be8518a15.  Is that not the case as that potentially could be the problem?

> Can you reproduce this with an initially-empty local database?

I'm reproducing this problem with a completely new CBL database each time.

> Would it be possible to use a build of the current master branch and try to reproduce the problem?

I can try this assuming it doesn't take too much configuration to upgrade.

> In either case, please file an issue on Github so we can track this.

Can I file the issue with the same information I started this discussion with?

Thanks for your prompt help Jens as it's greatly appreciated.

[David Quon]

Created issue https://github.com/couchbase/couchbase-lite-ios/issues/961 from this discussion.

[David Quon]

Hi Jens.  I added a bunch of our findings to the issue https://github.com/couchbase/couchbase-lite-ios/issues/961.  Let me know if you have any suggestions or ways we can work around the problem.  Thanks for your help.