How should I handle conflicts in couchbase lite if I use sync gateway?

We use sync gateway and couchbase lite. The current recommended way to handle conflicts in couchbase lite is to delete the revisions that have ‘lost’ and update the one that won. Ref here:
Part of the example code has this line for deleting the losing revision:
newRev.isDeletion = YES;

But doing this sets a field called _deleted = true on the document. Sync gateway does not allow any client to set internal fields (anything starting with _) so any revision handled this way is rejected by sync gateway and thus if the same conflict is later synced to a different device it has to handle it again. Is there a better way to handle conflicts in couchbase lite when we are also using sync gateway?

Sync Gateway doesn’t reject incoming documents with the _deleted property. It’s one of the leading underscore fields that it expects clients to be able to set.

If you’re seeing Sync Gateway reject those documents, can you provide some more specifics?

I see this error for any document that comes from the client with the _deleted flag (I changed the id fields slightly since I didn’t want to publicly post a real document id):

2017-02-21T07:00:46.061Z Sync fn rejected: new=map[_rev:2-4e06228ca6233e67c363a6a2c48e10bd _revisions:map[start:2 ids:4e08ca6233e67c363a6a2c48e10bd 07b50151a3837d416d8a768e7c73] _deleted:true _id:7ac14a5d-4ab3-888d-de50d5c33cdf] old= --> 403 invalid document
2017-02-21T07:00:46.061Z BulkDocs: Doc "7ac14a5d-4ab3-888d-de50d5c33cdf" --> 403 invalid document (403 invalid document)

My mistake about the deleted flag specifically though. When I tried to save with that it was ok, but if I use any other _ field I get this error:
“error”: “Bad Request”,
“reason”: "user defined top level properties beginning with '
’ are not allowed in document body"

You should expect to see the ‘user defined top level properties…’ error if the client is including a leading underscore field that’s not in the set: [_deleted, _revisions, _rev, _attachments, _id].

This would return a 400 error, though - not the 403 you’re seeing. It looks like the 403 is the result of your sync function rejecting the document.

Is that what you would expect to see for a deleted revision though? A stub with just _deleted, id, and _rev fields? I don’t want to allow it in the database unless it is what a deleted revision from the app is supposed to look like that.