You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I found that to batch a sequence of messages atomically from a contract, I had to reintroduce the following pattern:
enumMyContractMsg{Batch{messages:Vec<CosmosMsg>}}// In your handlermatch msg {MyContractMsg::Batch{ messages }if sender == self_addr => Response::new().add_messages(messages)
...
}// SomewhereResponse::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?
The text was updated successfully, but these errors were encountered:
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.
Hi,
I found that to batch a sequence of messages atomically from a contract, I had to reintroduce the following pattern:
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 changeSubMsg
to accept a list ofCosmosMsg
? Or perhaps introduce aCosmosMsg::Batch { messages: Vec<CosmosMsg> }
variant with a feature flag?The text was updated successfully, but these errors were encountered: