feat: nonatomic multimsg

[tac0turtle]

Summary

when using multimsg currently if one message fails in the batch the complete tx is reverted. There is a valid use case of allowing the messages that succeed, succeed, and error on the failed ones.

Proposal

Introduce a async multimsg endpoint allowing users to submit messages in batches but allow individual messages in the batch to fail. For the failed messages we should make sure to return detailed errors on why they failed.

[AdityaSripal]

Additionally, we'd like to be able to define a gas limit per message so that a message in the front of the queue does not consume all the gas in the tx.

cc: @ValarDragon

[robert-zaremba]

So we need to return a map of errors (msg index -> error).

[nicolaslara]

Introduce a async multimsg endpoint

This sounds to me like you would like an endpoint decoupled from the Tx itself (similar to authz.MsgExec)

I was thinking of adding this to the TxBody protobuf or as a supported-by-default extension_option and allow those to be set when submitting the transaction. Is that too intrusive?

[alexanderbez]

You'll eventually need to re-wire the plumbing in BaseApp to support this regardless of the top-level UX

[nicolaslara]

The draft PR I added there should give a rough idea of how I was thinking of implementing this. It still needs work (fixing the E2E test, review edge cases, add error events/list, deal with ante/post handlers, remove weird structs that won't be needed), but what do you think of the general design?

[08d2]

when using multimsg currently if one message fails in the batch the complete tx is reverted. There is a valid use case of allowing the messages that succeed, succeed, and error on the failed ones.

A transaction is, by definition, a group of operations that executes atomically. This is a core assumption of Tendermint, Cosmos, applications built on the SDK, and really all programs in general. It doesn't make sense for something called a transaction to "partially succeed" -- if messages need to succeed or fail independently, they must not be grouped into a single transaction.

[robert-zaremba]

There is a valid use case of allowing the messages that succeed, succeed, and error on the failed ones.

What is that valid use case, and why currently it can't be handled?

[tac0turtle]

What is that valid use case, and why currently it can't be handled?

This came up after a conversation with axelar where they use multimsg to submit many messages at once. They asked if it was possible to have a multimsg where if one msg failed the rest would still go through as they are not dependent. After this both ibc and osmosis asked for this.

thanks peter for your comments, but i implore you to understand the product before commenting. This has been asked of you before and it seems there has not been any improvement. Happy to help you onboard onto the product if needed.

[tac0turtle]

in discussion over the past few weeks we have concluded that we should avoid modifying the tx struct to add new features. Instead we propose adding this feature to the auth module, and later the accounts module. To close this issue for the next release we have to add it to the accounts module. This adds the limitation that a non atomic multimessage can only be signed by one user instead of many.

Due to malleability concerns around adding things to the tx we would like to limit the additions to the tx struct