{"action":"opened","issue":{"url":"https://api.github.com/repos/couchbase/sync_gateway/issues/1720","repository_url":"https://api.github.com/repos/couchbase/sync_gateway","labels_url":"https://api.github.com/repos/couchbase/sync_gateway/issues/1720/labels{/name}","comments_url":"https://api.github.com/repos/couchbase/sync_gateway/issues/1720/comments","events_url":"https://api.github.com/repos/couchbase/sync_gateway/issues/1720/events","html_url":"https://github.com/couchbase/sync_gateway/issues/1720","id":150658266,"number":1720,"title":"Replication inaccurate 403 forbidden ","user":{"login":"Crapulax","id":15442005,"avatar_url":"https://avatars.githubusercontent.com/u/15442005?v=3","gravatar_id":"","url":"https://api.github.com/users/Crapulax","html_url":"https://github.com/Crapulax","followers_url":"https://api.github.com/users/Crapulax/followers","following_url":"https://api.github.com/users/Crapulax/following{/other_user}","gists_url":"https://api.github.com/users/Crapulax/gists{/gist_id}","starred_url":"https://api.github.com/users/Crapulax/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Crapulax/subscriptions","organizations_url":"https://api.github.com/users/Crapulax/orgs","repos_url":"https://api.github.com/users/Crapulax/repos","events_url":"https://api.github.com/users/Crapulax/events{/privacy}","received_events_url":"https://api.github.com/users/Crapulax/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-04-24T12:50:54Z","updated_at":"2016-04-24T12:50:54Z","closed_at":null,"body":"Hi,\r\n\r\nIn link and as a continuation of issue https://github.com/couchbase/sync_gateway/pull/464, when then channel granting document is sent, within a bulk_docs, and after granted document the replication fails. Is there a smart way to handle such issue?\r\nWhat is hapenning is that when the SG process the granteed document it gets rejected by the validation function as the document granting the access has not been processed yet.\r\n\r\nAs far as I have seen there is no way on the client side to:\r\n1- catch in a programatic way that a replication error occured. The information about the document replication failure is in the couchdb log but nowehere else (not in _active_tasks) for instance. In active_tasks you only see the counter doc_write_failure increasing.\r\n2- inform the replicator to replicate document in creation order\r\n\r\nAs in the meantime you have no network garantee (from mobile) you are likely to run into this issue...\r\n\r\nI am looking on two ways to recover from this situation:\r\n1- Parse the SG logs from a server and request the client to update the offending document (assuming granting acces doc was replicated since then). Very dirty solution in my view. And not sure all further failed document will resync anyway.\r\n2 - Wait for grantor document replication to finish before creating depending documents. This is generating processing and complexity overhead on client side. It is also against the concept of  offline mode offered by couchbase-lite!\r\n\r\nYes this issue should probably more be handled on couchdb /. couchbase-lite sides but it is making the sync gateway usage difficult so you might probably want to handle it directly.\r\n\r\nbelow according logs from SG:\r\n016-04-22T16:11:50.899Z HTTP:  #108629: POST /XXXX/_revs_diff  (as 0ad9eed4-4e2c-43ae-9a0e-10f1bfe0d3cb)\r\n2016-04-22T16:11:50.991Z HTTP:  #108630: POST /XXXX/_revs_diff  (as 0ad9eed4-4e2c-43ae-9a0e-10f1bfe0d3cb)\r\n2016-04-22T16:11:51.002Z HTTP:  #108631: POST /XXXX/_revs_diff  (as 0ad9eed4-4e2c-43ae-9a0e-10f1bfe0d3cb)\r\n2016-04-22T16:11:51.059Z HTTP:  #108632: POST /XXXX/_revs_diff  (as 0ad9eed4-4e2c-43ae-9a0e-10f1bfe0d3cb)\r\n2016-04-22T16:11:51.118Z HTTP:  #108633: POST /XXXX/**_bulk_docs**  (as 0ad9eed4-4e2c-43ae-9a0e-10f1bfe0d3cb)\r\n************************************ debut XXXX USER *************\r\ntrue\r\ndoc id:a4422b6c3812b92d019d46766906f7fc\r\ndoc XXXXuser_id:0ad9eed4-4e2c-43ae-9a0e-10f1bfe0d3cb\r\ndoc pseudo:cccc\r\ndoc XXXX_id:-cvqi7DbLeyr7QzEblCI6dk\r\n************************************ fin XXXX properties\r\n2016-04-22T16:11:51.120Z **Sync fn rejected**: new=map[XXXXuser_id:0ad9eed4-4e2c-43ae-9a0e-10f1bfe0d3cb _revisions:map[start:1 ids:[5a1107e8fac754365cd79a9a67fc021\r\n5]] _id:a4422b6c3812b92d019d46766906f7fc _rev:1-5a1107e8fac754365cd79a9a67fc0215 pseudo:cccc creationDate:2016-04-22T16:11:40.263Z type:XXXXUser XXXX_id:-cvqi7\r\nDbLeyr7QzEblCI6dk]  old= --> 403 missing channel access\r\n2016-04-22T16:11:51.120Z        BulkDocs: Doc \"a4422b6c3812b92d019d46766906f7fc\" --> 403 missing channel access **(403 missing channel access)**\r\n2016-04-22T16:11:51.131Z HTTP:  #108634: POST /XXXX/_bulk_docs  (as 0ad9eed4-4e2c-43ae-9a0e-10f1bfe0d3cb)\r\n************************************ debut MESSAGE\r\ntrue\r\ndoc._id:a4422b6c3812b92d019d46766906feca\r\nmessage:Dhdhdh joins our XXXX!\r\nXXXX_id:-cvqi7DbLeyr7QzEblCI6dk\r\ncreator_id:0ad9eed4-4e2c-43ae-9a0e-10f1bfe0d3cb\r\npseudo:Dhdhdh\r\ncreationDate:2016-04-22T16:11:40.312Z\r\n************************************ fin msg properties\r\n************************************ fin message\r\n2016-04-22T16:11:51.191Z HTTP:  #108635: POST /XXXX/_bulk_docs  (as 0ad9eed4-4e2c-43ae-9a0e-10f1bfe0d3cb)\r\n************************************ debut INVITE ************ **This is the granting channel access doc**\r\ntrue\r\ndoc id:92002d59cc4ea4ab76499a583e4e002f\r\ndoc XXXXChannel:-cvqi7DbLeyr7QzEblCI6dk\r\ndoc invitedUser_id:0ad9eed4-4e2c-43ae-9a0e-10f1bfe0d3cb\r\ndoc inviteStatus:accepted\r\ndoc invitingOwner_id:abb20185-1955-450b-baf4-8a7a063827af\r\n************************************ fin XXXX invite properties\r\n************************************ fin INVITE *******************\r\n2016-04-22T16:11:51.879Z HTTP:  #108636: POST /XXXX/_ensure_full_commit  (as 0ad9eed4-4e2c-43ae-9a0e-10f1bfe0d3cb)\r\n2016-04-22T16:11:52.018Z HTTP:  #108637: PUT /XXXX/_local/73e62a7fb4d15bfe8778ea42f273db4d  (as 0ad9eed4-4e2c-43ae-9a0e-10f1bfe0d3cb)\r\n2016-04-22T16:11:52.066Z HTTP:  #108638: GET /XXXX/  (as 0ad9eed4-4e2c-43ae-9a0e-10f1bfe0d3cb)"}}