For collection/scope doesn't exist returning LCB_ERR_TIMEOUT will break the LCB_ERROR_IS_TRANSIENT since it will return true even if the code returned by kv is not retriable and application will end up retrying the request.
In eventing for now we fixed this by checking kv status code(lcb_errctx_kv_status_code) but we expect lcb to give more detailed error code when scope/collection doesn't exist.
Sergey Avseyev, Could you please take a look?

I think we've covered this previously Ankit Prabhu .  As bucket/collection creation proceeds asynchronously through the cluster, there is no way to really know if it should exist and doesn't exist yet or does not exist.

Because of that limitation, SDKs retry until timeout in order to address the UX behind the scenario where they use the management API to create a bucket or collection, then immediately try to access it.  That was an intentional design decision.  There were only two options given the interface from the cluster, one being retry until timeout, the other being fail to allow the bucket or collection to be accessed.

There is a plan to make this better in a future release.  See MB-46643 which is about collections and MB-111484.  

libcouchbase does have retry strategies which were discussed with the eventing team before.  If you want to handle these at a higher level, you can.  libcouchbase is working as intended here.

Matt Ingenthron, Looks like lcb doesn't retry till timeout for scope/collection not exist and request is made once to kv and pass that error message back to application as TIMEOUT.

The expectation here is that lcb gives proper error code(SCOPE_NOT_FOUND or COLLECTION_NOT_FOUND) instead of TIMEOUT.

These error can give LCB_ERROR_IS_TRANSIENT() true in which case application can take decision to retry or not.

Jeelan Poola I've asked Sergey Avseyev to look at this but he's dealing with some urgent relocation related activities right now. He should be able to respond early next week.