This question is not related to the changes specific to this PR, but it is related. Why do we "implicitly" create the transactions object when we create a cluster object in the public API? I don't get the sense that is what we need to do in order to support ExtSDKIntegration (ref Transaction instantiation). To me, it would seem better to lazily create the transactions object when users call cluster::transactions(). Is there something I am missing?

This question is not related to the changes specific to this PR, but it is related. Why do we "implicitly" create the transactions object when we create a cluster object in the public API? I don't get the sense that is what we need to do in order to support ExtSDKIntegration (ref Transaction instantiation). To me, it would seem better to lazily create the transactions object when users call cluster::transactions(). Is there something I am missing?

The spec doesn't specify this behaviour. It only says "The life-cycle of that Transactions object is now bound to the Cluster it's created from." and it appears to leave the details up to the implementation. However, I agree that it would be better to lazily create the transactions object to avoid spinning up all the transactions infrastructure for users who are not using transactions. A problem here is that transactions::create currently returns an error because of this bucket_open which would be inconvenient if it was returned via transactions() I think (since we return errors rather than throwing in the Public API).

I'll need to investigate further if we should actually be doing this bucket_open here or if we can just do the transactions create asynchronously and surface any errors elsewhere (e.g. on txn.run). If we end up doing this, we should be able to easily move the creation to transactions().

To me, it would seem better to lazily create the transactions object when users call cluster::transactions(). Is there something I am missing?

I agree, this is what we do with buckets, scopes and collections. Lets capture this as a ticket and discuss it separately. Maybe it should go one step further, and not just lazily create transaction object, but defer running background tasks and opening a bucket until first transaction will be scheduled.

To me, it would seem better to lazily create the transactions object when users call cluster::transactions(). Is there something I am missing?

I agree, this is what we do with buckets, scopes and collections. Lets capture this as a ticket and discuss it separately. Maybe it should go one step further, and not just lazily create transaction object, but defer running background tasks and opening a bucket until first transaction will be scheduled.

I've filed a ticket for this: CXXCBC-474