When a bucket is not configured, a configuration is created for the bucket in the runtime in the cluster object and it uses the password from the configuration which is configured on an entirely different bucket. Not sure if this is expected behavior, but for sure is misleading.
For eg, if there is Sample bucket configured in the config with a password say “password” and OpenBucket is issued on NotSample bucket for which there was no configuration, a configuration is created in the cluster object and the password shows “password”.
I see your point. The intention was to make it easy to open multiple buckets from a cluster object, so the cluster’s configuration is cloned (or via another existing bucket configuration) since the cluster’s nodes are already known (its post bootstrap at this point).
I think a simple solution here would be to remove the password from the configuration clone routine. Thoughts?
@jmorris I guess a more predictable way would be to have a default bucket configuration used instead of cloning. Probably something akin to what we have for a OpenBucket call wihtout args, default bucket opening with a default config. Since if there are multiple buckets configured then I’m not sure which config would be cloned for a bucket which has not been configured. Node related info can be used from the cluster object, like you said that isn’t going to change between buckets in a cluster
I opened up a ticket for a fix with the 2.2.6 release: https://issues.couchbase.com/browse/NCBC-1080
If you feel inclined, you can always submit a pull request (it’s a pretty straightforward fix to this method). If you do please include a simple unit test.