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
Note: this is intended for v0.16.0. It is also a large change and we could wait until v0.17.0 to implement it and for now just throw "unimplemented" error if any contract returns subcall. Let's evaluate this one well.
We need to add a new subcall_response entry point similar to #420, however, this entry point is only used internally in the keeper and not exported to any other module.
We also need to handle submessages in the Response. These have the following semantics:
Store the parent context
Wrap the current context/storage in a new context (with CacheWrap())
If a gas limit is set, and limit is less than current gas used, create a new gas meter with smaller limit and update context
Call the message in this new context (just as we handle messages)
If we set a custom gas limit:
If we get an OutOfGas error, charge the parent context the full gas allowance of this subcommand and return error
Otherwise, charge the parent context the actual gas used
If either cause an OutOfGas on the parent context, we don't catch that and allow it to abort the full connection
Check result and handle storage:
If success, Commit the CacheWrap to the parent storage
If error, "rollback" (drop) the CacheWrap
Return the result to the calling contract via new subcall_response entry point
If error, return a string error result
If success, return all events and data set in the submessage
Also add these events to the parent transaction (to return to original caller, just as normal messages)
We do not charge the instantiation cost (40.000 gas) on this subcall_response as the parent is assumed to be cached.
Process subcall_response result just like any other result
note that subcall_response from message 1 is processed before message 2
note all submessages (and their responses) are processed before all normal messages
You can test this with the reflect contract, with has a new HandleMsg::ReflectSubCall variant to test this, and just stores the subcall_response in the storage for later queries (and test assertions)
The text was updated successfully, but these errors were encountered:
This is based on CosmWasm issue CosmWasm/cosmwasm#691 and PR CosmWasm/cosmwasm#796.
Note: this is intended for v0.16.0. It is also a large change and we could wait until v0.17.0 to implement it and for now just throw "unimplemented" error if any contract returns subcall. Let's evaluate this one well.
We need to add a new
subcall_response
entry point similar to #420, however, this entry point is only used internally in the keeper and not exported to any other module.We also need to handle submessages in the Response. These have the following semantics:
subcall_response
entry pointsubcall_response
as the parent is assumed to be cached.subcall_response
result just like any other resultsubcall_response
from message 1 is processed before message 2You can test this with the reflect contract, with has a new
HandleMsg::ReflectSubCall
variant to test this, and just stores thesubcall_response
in the storage for later queries (and test assertions)The text was updated successfully, but these errors were encountered: