Giuseppe

> For the futures I'm not sure if it's a good idea or if we should at least add a helper method to get the value and close the future...

> I also suggest that the Future APIs should be reworked so that `MustGet` or `Get` close the future. Yes, I reached the same conclusion last week. > I think...

> Will submit some changes later as I rewrite part of the current ones and add `context.Context` also to the future get functions I just submitted the first part of...

I've completed my changes; a couple methods have been removed from the `Future` interface, I think this way it's easier to use it. By the way, the C FDB API...

If we want to further simplify this: 1. the `Close()` method can be removed 2. when a future is created, the `Get()` is called in background (this means the constructor...

> I think the current design of that is quite iffy, abstracting a normal transaction, and a transaction _provider_ that does retries as one I noticed that, but rather than...

> I have done some of my own changes here, with some opiniation: https://github.com/semisol/foundationdb > > I'll look into the changes here and get back with feedback soon. I checked...

Let me write what is (at least for me) an interesting problem regarding closing transactions: there are basically two use cases to support: 1. opening a transaction, creating some futures,...

> `retryable` returns only when it is not possible to retry anymore, so closure in that case is correct. It is not correct IMO because closing a transaction implicitly cancels...

On this topic: I managed to inject that information (zone) by using the `ADDITIONAL_ENV_FILE` (was around the time I made [this PR](https://github.com/FoundationDB/fdb-kubernetes-operator/pull/1980))