Providing this here as alternative: we could probably use the sender to send a vec![transaction_guard] and let the TransactionConsumer pretty much do what it was doing before without any significant modifications apart from caching now multiple transactions instead of only one if we get over allowed size. Then a this point we just need to return/wait on the returned inlucluded_in_block_ack . I think the optimisation of using one ack sender makes sense, but I feel that it complicates a bit things on the TransactionConsumer side.

Thanks for pointing this out!

I guess in that case we need to spawn a separated task to wait on multiple oneshot channels (one for each TransactionGuard), then after all channels have been signalled, the task eventually signals the oneshot channel returned by submit_no_wait. I am not quite familiar with the runtime so not sure how much burden will this create.

Or we could actually change the API to remove the 'no wait' semantic - since it is already async.

I can proceed either way if people are okay with it.

I think we can use something like futures::future::join_all() to await on all oneshot channels without spawning a new task. But I'm not sure if it is an improvement over using only one ack callback. Maybe keep the current logic and we can iterate on this part in future? Wdyt @akichidis?

Yeah anything like futures::future::join_all() would do here , even a simple loop, as it's all or nothing. @mwtian it's not a performance improvement but rather , to my view, a complexity improvement. I felt that with the current approach there is lots for break up/ management in the TransactionConsumer which I would avoid. Just to be clear, not a deal breaker as solution, but that would be my preference.

I think we can use something like futures::future::join_all() to await on all oneshot channels without spawning a new task. But I'm not sure if it is an improvement over using only one ack callback. Maybe keep the current logic and we can iterate on this part in future? Wdyt @akichidis?

Just to reconfirm, based on the SIP-19 Note that the Soft Bundle API does not provide a strict ordering guarantee. However, it does provide an extremely high probability of being ordered correctly. , the intention is best effort to fit multiple transactions in the same batch, right ?

Also how do we intend to measure the successful inclusion of the soft bundle transactions in same batch/block? I assume the appearance in checkpoints would be one way if lower level metrics don't make much sense

the intention is best effort to fit multiple transactions in the same batch

That's right! The intention is to include the txs as a bundle if feasible to do so. The pre-existing constraints (e.g. batch size limit) are there for a good reason, so that should come first. It is alright for a Soft Bundle to fail.

I assume the appearance in checkpoints would be one way if lower level metrics don't make much sense

Exactly. It seems natural for the client to monitor the bundle it submitted, by looking at whether transactions are ordered as specified in the eventual checkpoint. If the bundles are failing frequently, one can tell that something must be wrong.