Details
-
New Feature
-
Resolution: Fixed
-
Major
-
None
-
None
-
1
Description
The only reason to go to a verbose http config is that if the terse one is not found: to be specific, a 404 is returned from the server. For all other errors there is no reason to arbitrarily fall back to verbose if terse didn't work. This is important, because the verbose one does NOT include nodesExt and as a result will fail to recognize services like query.
This could lead errors similar to the following:
com.couchbase.client.core.ServiceNotAvailableException: The Query service is not enabled or no node in the cluster supports it.
|
at com.couchbase.client.core.RequestHandler.checkFeaturesForRequest(RequestHandler.java:277)
|
at com.couchbase.client.core.RequestHandler.dispatchRequest(RequestHandler.java:247)
|
at com.couchbase.client.core.RequestHandler.onEvent(RequestHandler.java:208)
|
at com.couchbase.client.core.RequestHandler.onEvent(RequestHandler.java:79)
|
at com.couchbase.client.deps.com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:150)
|
We should only try the verbose endpoint if the terse one failed with a 404 (which is turned into a ResponseStatus.NOT_EXISTS). In all other cases the error is propagated which will turn into an error in the loader and a retry attempt in the refresher case. Most importantly, it will make sure that we will never fetch a verbose config if for some reason the terse one failed with an error other than a not found.