ICS26 Spec inconsistencies and improvements about ibc-go HOT 1 CLOSED

• Spec always calls module handler ("callback") before calling IBC handler. Code alternates
• eg. ChanOpenInit/Try call the IBC handler first, module handler (callback) second, while OpenAck/Confirm do the reverse
• eg. handlePacketRecv and handlePacketAck spec calls app handler first, code calls IBC handler first
• does it matter what order these are called in ? Should we be consistent?

I opened an issue in the spec repo asking if the spec should be updated to match the implementation.

• handlePacketRecv in spec doesnt write the ack; in code it does

The spec says that The writeAcknowledgement function is called by a module and I guess that module is, in ibc-go, the routing module. I will check with @AdityaSripal if this something that should be added to the pseudocode of handlePacketRecv in the ICS26 spec.

• All returned results are empty - any data is sent through events.

This is not the case anymore, some of the responses contain some data, like MsgChannelOpenInitResponse and MsgChannelOpenTryResponse.

• Inconsistency in where events are emitted. For client and connection handlers, events are emitted in the ICS26 code. For channels, events are emitted in ICS04 code.

Currently no events are emitted in ICS26, but in the corresponding handler code (client, connection or channel).

• ICS04 handshake handlers return sdk.Result containing events, but they're ignored

This is not the case anymore.

• App module packet callbacks return sdk.Result containing events, but they're ignored (onReceive/Timeout/AcknowledgePacket)

This is also not the case anymore.

• packet-based telemetry code in RecvPacket/Timeout/TimeoutOnClose can be deduplicated

This is still applicable, but I consider this really low priority and I honestly think there's not much to gain by deduplicating this code...

So I think I will close the issue for now, since there's not really any action item for the implementation. There could be some updates needed in the spec, but I will make sure to open issues in the spec repo for those if necessary.

from ibc-go.