Return IBC packet sequence number in the handler_plugin

[LaurensKubat]

For certain use cases, such as handling packets to ICQ and ICA hosts, the smart contract needs to connect outgoing packets to incoming acknowledgements to be able to handle the internal serialized bytes of the acknowledgement. To do this, the IBCRawPacketHandler DispatchMsg method should return the sequence number in some format. This could be a protobuf, for example

message IbcSendPacketResponse {
  // sequence number of the transfer packet sent
  uint64 sequence = 1;
}

for an example of needed changes; see here

[webmaster128]

Excuse my beginner Go, but I don't understand the diff. Where does the data variable come from and where does it go? How does the encoded sequence become available in the contract? Can it be process in a call to the reply entry point?

[LaurensKubat]

data is a named return value here. In the reply entrypoint, it is indeed the data field of a SubMsgResponse, so we can parse the sequence number by doing something like

let data = msg
        .result
        .into_result()?
        .data
        .ok_or(ContractError::NoReplyData)?
 let seq_resp = MsgTransferResponse::decode(data.0.as_slice())?;

(reusing the existing MsgTransferResponse proto here)

[webmaster128]

Thank you, got it. In this case we should indeed have a MsgIBCSendResponse to cosmwasm.wasm.v1.MsgIBCSend to return such data in a consistent and extensible fashion.

[ethanfrey]

I think returning packet number is good.
Even better is a query that you can do before sending, to know the next sequence number (to avoid need of reply).

I wouldn't use Protobuf interfaces but JSON, like the rest of the APIs we use in CosmWasm. Protobuf is for decoding raw data from the sdk

[LaurensKubat]

querying the next sequence number would be the best option. The main reason for using protobuf would be to keep the same interface between ics-20 transfers and raw ibc packets, but being able to query the next sequence number for both would also solve that

[webmaster128]

A synchronous query for data that is created as part of the message execution does not work well with the actor model. The sequence can easily be a different one the moment the MsgIBCSend is executed. E.g. like this

1. Query sequence
2. Emit a MsgExecuteContract that does things we don't know for sure, such as sending IBC packets
3. Emit MsgIBCSend which creates an IBC packet with a different sequence than the one from 1.