I hope someone can point me in the right directions, after upgrading my sync gateway from 3.0 to 3.2, the replicators are no longer able to sync with the following error in the logs:
2025-02-04T16:25:53.850+02:00 [ERR] c:#129 db:loads #129: authentication failure - possible reasons - incorrect authentication configuration, bucket doesn’t exist or bucket may be hibernated | {"statement":"SELECT meta(sgQueryKeyspaceAlias).xattrs._sync.access.`testdevice123456` as `value` FROM `loads.v3`.`_default`.`_default` AS sgQueryKeyspaceAlias USE INDEX (sg_access_x1) WHERE any op in object_pairs(meta(sgQueryKeyspaceAlias).xattrs._sync.access) satisfies op.name = $userName end;","client_context_id":"1d762413-6e15-4ca2-a555-7bee5f13cec5","errors":[{"code":10201,"message":"Invalid query_context specified: : too many context elements"}],"http_status_code":500} -- rest.(*handler).writeError() at handler.go:1613
Currently running syncgateway 3.2 and couchbase server 7.1.3 any advice would be much appreciated.
The error message says there is an authentication error. This can be from incorrect credentials or the bucket is hibernated or does not exist. Can you check that? Are you able to access that same bucket with those credentials by other means? Another possibility - bit of a long shot - but if you have multiple clusters, make sure that your connection string is pointing to the clustet with that bucket.
I think this actually may be a Sync Gateway query bug related to bucket names containing . characters, in your case, loads.v3. Looking at the inner error reason, it’s related to an invalid query keyspace.
I have reproduced this error on Server 7.1.3 and 7.6.4 attemping to create a user on a database with a bucket name containing .
I have also encountered a different SG error creating databases on buckets containing . in 3.1.x - so it seems like there’s a gap in support for buckets containing . characters, at least since 3.1.0
Would recommend a different bucket name delimiter just to avoid these issues, but I’ve filed a bug to investigate whether there’s any more query escaping we need to do to prevent these issues in future.
Thank you so much for the assistance here, we where concerned it was the bucket name but saw that the loads.v3 was escaped in the query giving the error and so wrote that off.
We managed to resolve it by reverting back to sync gateway 3.0.3, unfortunately changing the bucket names is quite a large refactor for us. To confirm is this something that should be supported or will we need to refactor away from that naming long term?
As usual your support and responsiveness on this forum is incredible
It is something we should be supporting, so if you’re able, please wait for a fix to upgrade to, rather than changing anything on your side.
We’ve narrowed this down to a Go SDK change which we picked up between SG versions and unfortunately isn’t a result of query escaping on the Sync Gateway side. We’ve looped in the SDK team to determine an appropriate fix - sorry for the inconvenience!