Details
Critical Description
When we do a cluster.query we check the cluster version via an http call to /pools, to decide whether or not to use the cluster or an open. bucket. This is because of CCBC-1204. But, the cloud doesn't give us a /pools - we end up seeing an exception like this:
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/couchbase/cluster.py", line 596, in query
|
err_msg="Query requires an open bucket")
|
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/couchbase/cluster.py", line 611, in _maybe_operate_on_an_open_bucket
|
if self._is_6_5_plus():
|
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/couchbase/cluster.py", line 547, in _is_6_5_plus
|
response = self._admin.http_request(path="/pools").value
|
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/couchbase/management/admin.py", line 165, in http_request
|
timeout=timeout)
|
couchbase.exceptions.NetworkException: <Key='/pools', RC=0x418[LCB_ERR_NETWORK (1048)], HTTP Request failed. Examine 'objextra' for full result, Results=1, C Source=(src/pycbc_http.c,212), OBJ=HttpResult<rc=0x418[LCB_ERR_NETWORK (1048)], value=None, http_status=0, url=/pools, tracing_context=0, tracing_output=None>, Context={'response_code': 0, 'path': '/pools', 'response_body': '', 'endpoint': 'cb-0000.f0b4027e-3f83-44de-bb01-6fb7217ab85b.dp.cloud.couchbase.com:18091', 'type': 'HTTPErrorContext'}, Tracing Output={":nokey:0": null}>
|
So - you cannot query, search, or analytics_query right now.
Simplest workaround, try cluster first, if that fails try the bucket (if any are open). Ideally we'd have a way to determine that we were successful, and continue without trying the failed path first. However that is tricky since we don't know if we failed because the cluster was not complete (say, query service nodes are down), or because of the version. Maybe we can discern the difference? Lets see if we can. Otherwise, just do the cluster and fall-back to the bucket. When CCBC-1204 is fixed, we should eliminate this code. In fact there should be a ticket to do that as well.
Attachments
Activity
Ah, interesting... I took this over because it seems at least tangentially related to PYCBC-950.
I forgot that the errors come up later (when you iterate over the results). So – lets instead note the error we get when checking the instance, and assume (if a network error) it is the cloud. Also, we should have always remembered this result and only done this once. Now we do. With the exception of this error, since it could be transient network issue (no way to tell the difference I believe).
Ideally we will rip this out when 3.0.3 lcb is out, as CCBC-1204 is slated for that release, and is supposed to fix this issue. However... we have to get this out now, and there are a lot of things currently in 3.0.3.