Getting document increments the revision


We are facing a really strange behavior which caused revision increase. What we do is really simple, through sync gw rest api, we open a document in our browser with get call. However, each refresh, increments the revision by one. When I checked the logs, I saw the below lines:

   2019-09-17T08:23:46.944Z [INF] HTTP:  #3284: GET /abc-db/WorkOrder::123(as ADMIN)
   2019-09-17T08:23:46.949Z [INF] Import: Created new rev ID 56-3d4690bb5fc7b07ef45f651aa6fb7178

Moreover, this won’t happen other types of document, only the documents whose type field is WorkOrder are affected. The bad thing is we use a web socket in our backend app and listen all the changes. Hence, we want to understand this issue and get rid of it.

Lastly, our couchbase server version is 5.0.0 build 3519 and sync gw version is 2.1.1(17;fea9947).


That Import: Created new rev ID is kind of suspicious. IIRC, it comes from the old “bucket shadowing” feature that’s no longer used/supported. I have no idea why it’d be happening here. Do you have something else running on Couchbase Server that would be updating the doc with that key?

(cc: @adamf)

It’s not the bucket shadowing import, but rather the shared bucket access import.

It looks like Sync Gateway is performing an on-demand import upon retrieval of that doc, primarily because it thinks something else has written to that document since Sync Gateway, and so we need to update our metadata (by generating a new revision). This external write could be a Couchbase SDK, Eventing process, etc.

@glenn Do you know of any scenarios in which your document could be modified in the bucket, rather than through Sync Gateway?


We listen change feeds via web socket and based on the update, we perform some extra actions in sdk level. In the log file, we saw that a new change occurred. However, this is very odd because this change has to dropped to us after this document gets a new revision. There is no any other mechanism or system which may cause document update. As I said, refreshing the browser triggers this problem.

I just thought that, can it be related with cas value? In our design, when our backend app catches a change, it gets & locks the document. If there is no additional update required to this document, we simply unlock this document by giving the cas value. This cas value is put into map when we make the first retrieval operation. After the unlock operation, we remove it from the map.