Add async support to wasm hooks #5072
Conversation
|
This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. Thank you! |
x/ibc-hooks/README.md
Outdated
|
|
||
| --- | ||
|
|
||
| TODO: I think this is overcomplicated and I can't remember why I wrote it like this. |
There was a problem hiding this comment.
@ValarDragon do you have any opinions on the design alternatives? (more info below this line and in the readme in general)
There was a problem hiding this comment.
I'm probably going to leave the implementation as-is right now to avoid increasing the surface area to test, and we can iterate on unifying this into one message later on.
x/ibc-hooks/wasm_hook.go
Outdated
| if err == nil { | ||
| // If unmarshalling succeeds, the contract is requesting for the ack to be async. | ||
| if asyncAckRequest.IsAsyncAck { // in which case IsAsyncAck is expected to be set to true | ||
| // TODO: Do we want to check that only whitelisted contracts can do AsyncAcks? |
There was a problem hiding this comment.
@ValarDragon also here. Any thoughts?
There was a problem hiding this comment.
Asking to learn: why do we want to whitelist this functionality?
There was a problem hiding this comment.
Discussed offline, whitelist makes sense to me
| func (m MsgEmitIBCAck) ValidateBasic() error { | ||
| _, err := sdk.AccAddressFromBech32(m.Sender) | ||
| if err != nil { | ||
| return sdkerrors.Wrapf(sdkerrors.ErrInvalidAddress, "Invalid sender address (%s)", err) | ||
| } | ||
| return nil | ||
| } |
There was a problem hiding this comment.
Does it make sense to do additional validation of packet sequence and channel here?
There was a problem hiding this comment.
I don't think we do. The packet sequence is an uint64, and the channel can be any string (even if they generally are channel-<number>
x/ibc-hooks/wasm_hook.go
Outdated
| if err == nil { | ||
| // If unmarshalling succeeds, the contract is requesting for the ack to be async. | ||
| if asyncAckRequest.IsAsyncAck { // in which case IsAsyncAck is expected to be set to true | ||
| // TODO: Do we want to check that only whitelisted contracts can do AsyncAcks? |
There was a problem hiding this comment.
Asking to learn: why do we want to whitelist this functionality?
Co-authored-by: Dev Ojha <[email protected]>
|
This is ready for final review and merge |
|
This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. Thank you! |
* added initial async ack support for wasm hooks * added initial working implementation of async acks * removed debug prints * cleanner acks * Update x/ibc-hooks/README.md Co-authored-by: Dev Ojha <[email protected]> * added use case to readme * clippy * clippy * updated hooks to latest * added changelog * updated deps * added proto fix and todo * added initial implementation of ack errors * make protos * better readme * cleanup rust structs * initial params * fixed test * updated async acks based on feedback. Safer this way * add error ack test * added missing types * updated ibc-hooks * tidy * updated osmoutils * updated osmoutils and ibc-hooks after merge * merge main * regen proto * update osmoutils * update ibc hooks * run go get * rl bytecode --------- Co-authored-by: Dev Ojha <[email protected]> Co-authored-by: Adam Tucker <[email protected]>
What is the purpose of the change
Packet Froward middleware introduced "async" acknowledgements in IBC: when onRecvPacket runs, the ack doesn't need to be written to state right away. Instead, that function can return
niland someone else (ideally the same module that received the packet) will write the acknowledgement later. If this doesn't happen the packet will timeout.We want to add support for this in ibc wasm hooks so that whitelisted contracts (specifically XCS) can do this and behave similarly to PFM. This will provide a better UX when interacting with contracts that forward tokens.
Brief Changelog
Testing and Verifying
Documentation and Release Note
Unreleasedsection inCHANGELOG.md? (yes / no)x/<module>/spec/) / Osmosis docs repo / not documented)