Receive 404 from server for _local documents


In our sync gateway logs I see a few 404 errors for some _local document calls. I don’t fully understand what the _local indicator means, or why our server is being called for them. The info I could find on them said they were for metadata for the local couchbase lite DB only:

404 Errors for them in the sync gateway log:

22:06:19.386904 HTTP:  #131295: GET /todos/_local/36e42c5fde29274cc905bdcacb1aa015a48bbc28  (as f5cf12b4-3a0b-42ab-8dcb-55b6f19ce80c)
22:06:19.387543 HTTP: #131295:     --> 404 missing  (2.1 ms)
22:06:19.684164 HTTP:  #131296: GET /todos/_local/a9d0406b06530f486a588af36986b26318f7ed5f  (as f5cf12b4-3a0b-42ab-8dcb-55b6f19ce80c)
22:06:19.684563 HTTP: #131296:     --> 404 missing  (1.9 ms)

How come the couchbase lite client is querying for these documents on our server? I only see a few 404 errors for these _local queries too, but how could sync gateway be successfully returning documents that shouldn’t be on the server? Some of our users have been having syncing issues where they receive all public documents ok, but then documents for specific channels they are a part of don’t sync to them the first couple times they try. Could this be related to that issue?

PULL after PURGE no docs are returned

Hi @alexegli,

That’s a very good question! I will try to explain why /{db}/_local/{id} requests are made.

Databases in Sync Gateway or Couchbase Lite have a sequence number that is incremented every time something changed in the database (document insert, update, delete…).

The replications (push or pull) are responsible for mirroring the source database to the target database. To avoid replicating already synced revisions, the source and target databases store the last source sequence number for that particular replication (corresponding to the last source change operation that was successfully replicated to the target).

To continue from where a source/target pair were last synced, the replicator will first retrieve that last source sequence number from both the source and target (hence the HTTP call to /{db}/_local/{id} to retrieve the last source sequence number from the target).

If it’s the first time a replication is performed then /{db}/_local/{id} returns a 404 since they never synced before and the target doesn’t have a local document containing the last source sequence number.

You can read more about it here.

I don’t think the syncing issue is related to this.

It looks like these are one shot pull replications. The retry button scenario can usually be solved by using continuous replications but I understand it may not be the best fit for every use case. It would be great to have a little more detail to try to reproduce this. It’s interesting that you are only observing this behaviour for documents in a channel the user has access to and not the public docs. Are the public docs in the ! channel? How are the documents saved to SG the first time? (through another device syncing or the REST API or bucket shadowing?)




I see that there is a local document feature in Couchbaselite. This will keep the document locally and not replicate and the documentation says start it with _local.

If I try to insert the document like this where idMem = “_local”+idMem
config.db.put(idMem, screenDoc, function(err, ok), the function errors out and does not insert.

I am using Phonegap and this is being called from the js file. Please advise.