String "seq" breaks CouchDB compatibility



I have been developing and testing with sync gateway and found that the “seq” identifiers in _changes are sometimes ints and sometimes strings with a pair of ints separated by two colons.

When they are strings if I restart the gateway they return to being ints.

Being strings seems to break the gateway web console but more crucially for me breaks compatibility with CouchDB which I guess expects ints. Could the additional int which seems to encode some state from the gateway (which is meant to be stateless) be included as a second attribute instead? This would preserve compatibility and be prettier. (What is the second int?)

I am using local CouchDB with the Sync Gateway as I haven’t managed to build a stand alone non android Java CBLite with both listener and js. Has anyone built one?

I’m using:

Couchbase Sync Gateway/master(1c6559c)
Server 3.0.1 Community Edition (build-1444)




CouchDB doesn’t require ints. It’s always been the case that sequences in the replication protocol are arbitrary JSON objects. Both BigCouch and Cloudant use long base64-format strings, for example.

SG should be compatible with CouchDB. If you’re having trouble, please post details of exactly what goes wrong.


Hi Jens,

I’ve just been looking at this again.

I am adding a small number of docs to couchbase via the sync gateway and they all appear ok in couchbase, but when I replicate to a CouchDB database or use curl to get changes I am only seeing some of the docs. This seemed to coincide with the int/string seq identifiers but maybe this was coincidental. I have run this test again and this time I am not getting any string seq but both _changes via curl and replication only show docs up to 16 whereas they actually go higher in couchbase. There is an example of this below.

Looking at the sync gateway web ui it sees all the docs in couchbase ok but has failed to build the correct channels or to preview the sync function.

If I restart sync gateway the web UI works and _changes and replication works ok.

I have repeated this a few times, always curl changes gets the wrong last_seq, sometimes the gateway web UI partially fails and sometimes replication to CouchDB hangs

I will try and narrow this down to a more simple reproducible test



Pauls-MacBook-Pro :: ~ » curl http://test:password@“sync_gateway/bychannel”&channels=domain_test
Pauls-MacBook-Pro :: ~ » curl http://test:password@“sync_gateway/bychannel”&channels=domain_test&since=16

but this is in the db and ought to show up too

"_sync": {
“rev”: “1-3b13e9634415d4c3fa3d6f2b99b6f8fc”,
“sequence”: 35,
“history”: {
“revs”: [
“parents”: [
“bodies”: [
“channels”: [
“channels”: {
“domain_test”: null,
“project_83b7c934-5f03-40f5-83b7-50d2fcd83ed3”: null
“access”: {
“paul”: {
“project_83b7c934-5f03-40f5-83b7-50d2fcd83ed3”: 35
“time_saved”: “2015-05-20T18:45:04.104865177Z”
“access”: [
“channels”: [
“domain_id”: “domain_test”,
“name”: “test_project”,
“namespace”: “”,
“owner_id”: “test_person”,
“rackspacestore_id”: “rackspacestore_test_project_83b7c934-5f03-40f5-83b7-50d2fcd83ed3”,
“recipe”: “”,
“type”: “project”


Looks like the recent-changes cache gets out of date, since that doc should be showing up (and does after restarting the gateway, you say.)

Could you please file an issue against SG on Github?


If you can include the Sync Gateway logs when making the _changes request (that doesn’t return the expected sequence 35) when you file the ticket, it will help us try to reproduce the issue.