Delete document doesn't sync

I’m experiencing a weird behavior when deleting a document. I explain the situation better. I have an admin panel where I call the delete api: dburl/db/docId?rev=revId.
From the device/simulator it doesn’t catch the change event on this deletion while on update and on new document it behaves perfectly. Does anybody has any idea why it happens?my sinc_gateway.json is just plain now without any channels set.

{
“log”: [“HTTP+”],
“adminInterface”: “127.0.0.1:4985”,
“interface”: “0.0.0.0:4984”,
“databases”: {
“db”: {
“import_docs”: true,
“server”: “http://192.168.22.23:8091”,
“bucket”: “storeapp”,
“users”: {
“GUEST”: {“disabled”: false, “admin_channels”: ["*"] }
}
}
}
}

After various restarts of the machine now it works properly the deletion too, all without changing a bit of code…We are seriously worried that it could happen in production environment. Is this technology tested enough?

I tried to change the channel (one and only channel ,for example ‘model’ to ‘newmodel’), then called the 3 sync api: db/_offline , db/_resync, db/_online.
I can see that in couchbase admin panel all docs get updated in revision and assigned to ‘newmodel’ channel.
Then I tried to delete a document that comes from api call to all_docs (I noticed that all docs come with an old revision id and not the latest one, also refreshing the page and calling all_docs it gives the same result) and of course deletion returns a conflict in revision. What should I do the right way?How conflicts should be managed?Why all_docs doesn’t send the latest revision ids but a previous one?

Deleting a document via the app or via DELETE REST API on sync gateway should be replicated.Deletions are effectively updates to the document revision tree.
So it should definitely work without requiring a restart of the machine.

Next time you encounter this issue, can you please collect logs from the Sync Gateway. Also, please include versions of components that you are using.

Can you please move your question to a separate thread. This question seems unrelated to the original question.