TransactionContextWrapper is an internal indirection used by TransactionProxy in ask-based protocol implementation. It handles the eventual completion of shard lookup, without blocking operation allocation. This has a non-trivial price in that each wrapper has a queue, plus each operation has to check whether the context is resolved and potentially replay the queue.

While this need is unfortunate – and would be better served through proper sharding, MDSAL-427, or tell-based protocols reconnect logic – we should be able to improve on the situation at least for the local-leader case.

The way the code is currently structured:

1. we allocate TransactionContextWrapper, which has no side-effects
2. we kick off ShardInfo resolution, obtaining a Future
3. check if the Future has completed, shortcutting completion codepath
4. return the wrapper

While this works and shares codepaths, we should be able to do better if we realize that the context is not visible to user if we are taking the shortcut at 3, and if maybeCreateLocalTransactionContext() returns a valid local context have everything ready to completely bypass the 'no TransactionContext' case. This same is true if we end up with an immediate failure.

We should therefore be able to specialize TransactionContextWrapper so that we have a simple no-queuing implementation for those immediately-satisfied cases, as operation queueing in those cases is a lot more direct and less memory-hungry.