Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Batch execution of submessages #1868

Open
hussein-aitlahcen opened this issue Sep 7, 2023 · 1 comment
Open

Batch execution of submessages #1868

hussein-aitlahcen opened this issue Sep 7, 2023 · 1 comment

Comments

@hussein-aitlahcen
Copy link
Contributor

hussein-aitlahcen commented Sep 7, 2023

Hi,

I found that to batch a sequence of messages atomically from a contract, I had to reintroduce the following pattern:

enum MyContractMsg {
 Batch { messages: Vec<CosmosMsg> }
}


// In your handler
match msg {
   MyContractMsg::Batch { messages } if sender == self_addr =>  Response::new().add_messages(messages)
   ...
}

// Somewhere
Response::new().add_message(SubMsg::reply_on_error(REPLY_ID, wasm_execute(self_address, MyContractMsg::Batch { messages }))

The idea here is to execute N messages and get a single reply if any of them is failing (and also revert any state change made by a message in this sequence). In this case, we re-dispatch a contract message with the sequence and execute them from there, the top level reply_on_error is then executed when the previously mentioned case happen (any message error, everything is reverted). Is there a more idiomatic way to do that? If not, maybe it would be interesting to change SubMsg to accept a list of CosmosMsg? Or perhaps introduce a CosmosMsg::Batch { messages: Vec<CosmosMsg> } variant with a feature flag?

@chipshort
Copy link
Collaborator

That looks like a nice solution to me.
I don't think we need add an additional message for something that can be achieved this nicely in contract code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants