Add docs on Error handling for ibc_packet_receive

[webmaster128]

Rendered version here: https://github.com/CosmWasm/cosmwasm/blob/ibc_packet_receive-erros/docs/ERROR_HANDLING.md

[ethanfrey]

Very nice article. Minor comments about how much detail we want.

Fine if you ignore the second comment as TMI, but wanted to bring it up.

[0xekez]

this is excellent documentation. thank you!

[0xekez]

some additional questions i have thinking about this a little:

1. will the SDK ever override a success ACK?
2. what exactly are the rules for what i can send in a packet? for example, empty string values are not allowed.

these may be more general SDK questions, so let me know if they're out of scope.

[alpe]

I don't fully understand how the StdAck is handled downstream. It is important to consider the state commit/rollback for "errors" scenario 2 and 3

Scenario 3:

If the "error" is returned to wasmd as IBCReceiveResult.Err, then the state is rolled back and the error text redacted (currently) and serialized into the json format above.

Scenario 2:

If the "error" is returned to wasmd as IBCReceiveResult.Ok.Acknowledgement then the data is returned as it is with the state committed. I assume StdAck is doing this but I may got it wrong

[alpe]

Good questions:

1. will the SDK ever override a success ACK?

The ACK data is not overwritten but if any panic happens downstream in ibc-go or SDK (due to out of gas for example) the TX would roll back and no state would be persisted.
More likely to cause trouble are submessages returned with the IBCReceiveResponse. They would be processed before the ACK is passed downstream to ibc-go. For example, if a bank transfer submsg fails due to out of funds then the redacted error would be returned as ErrorAck instead of the contract's success Ack.

2. what exactly are the rules for what i can send in a packet? for example, empty string values are not allowed.

An IBC packet is a raw bytes slice. You can put any data in there that makes sense for you. Can json, proto or any custom format. The total length of this packet data must be >0 or it will be rejected in ibc-go packet validation.
For the error returned by the contract, we do not have constraints. An empty string would be possible but does not make much sense.
I will add a note to CosmWasm/wasmd#1289

[alpe]

It would be good to document behaviour for contract/ sub-message events for the success/error Ack scenario as well.
I have noticed that we were relying on downstream event handling which is not intuitive. See CosmWasm/wasmd#1288 for context and discussion

[chipshort]

This is very important info. Would be great to merge this.
I have added a suggestion for the changes we made in 2.0.

[chipshort]

LGTM

[webmaster128]

Thank you, Chris!