Unknown source trying to save stub documents to sync gateway


I see lot of log entries in my sync gateway logs that look like something is trying to save a stub deleted document, and since we require all documents to have a type field it fails as a 403 error. There is no user associated with the request to save the stub document either. Is this something normal that sync gateway itself is trying to do, and if so is there a special permissions check I can do that will allow sync gateway to save these stub documents? The log entry looks like this:

2017-04-20T14:08:39.369Z Sync fn rejected: new=map[_rev:2-4e06228ca6233e67c363a6a2c48e10bd _revisions:map[start:2 ids:[4e06228ca6233e67c363a6a2c48e10bd 4b8d13da9c3f83093f25b524ffe9d4e6]] _deleted:true _id:8d787620-bc99-445f-8040-bd88c9ab89fe]  old= --> 403 invalid document
2017-04-20T14:08:39.369Z 	BulkDocs: Doc "8d787620-bc99-445f-8040-bd88c9ab89fe" --> 403 invalid document (403 invalid document)



Sync Gateway does not do this internally.

From the log snippet it looks like this is happening as part of a BulkDocs call from a client that is doing a push replication.

Prior to the log entry posted can you see an HTTP log entry for the incoming REST API _bulk_docs call, for the ADMIN API this will look like:

2017-04-21T13:08:38.849+01:00 HTTP: #001: POST /db/_bulk_docs (ADMIN)

for the PUBLIC API this will look like:

2017-04-21T13:09:33.165+01:00 HTTP: #001: POST /db/_bulk_docs (as )



Thanks, we have a pretty busy log but if sync gateway doesn’t do that by default then it must be couchbaselite. I’m not sure what couchbase lite is doing but it looks like a conflict revision. We’ll have to investigate it more on our side to see why couchbase lite is trying to save empty deleted stub documents.