Cosmos-sdk: Inconsistency between ConnectionEnd in ICS vs cosmos-sdk

Created on 16 Jul 2020  路  6Comments  路  Source: cosmos/cosmos-sdk

Summary of Bug

ConnectionEnd in ICS does not have the "local" connection ID while it is included in cosmos-sdk implementations and the ConnectionEnd included in query responses (included in the protobuf definitions).
For channels, ChannelEnd in ICS matches the Channel in cosmos-sdk in the sense that "local" parameters (port-id and channel-id) are not included there. For queries that return multiple channels there is an IdentifiedChannel structure that includes the "local" parameters.

Also, should the queries for multiple channels and connections be required by standard and therefore documented in the ICS-es? This would be useful for the relayer :)

Version

master

Steps to Reproduce

N/A - just looking at the code and specs


For Admin Use

  • [ ] Not duplicate issue
  • [ ] Appropriate labels applied
  • [ ] Appropriate contributors tagged
  • [ ] Contributor assigned/self-assigned
ibc

Most helpful comment

For "query all connections" query, the id along ConnectionEnd is useful. For channels there is the IdentifiedChannel struct.

We can create an analogous IdentifiedConnection, I expect.

All 6 comments

cc @cwgoes

I like the idea of defining what query functions TAO should support.

I think the relayer guide #6483 should probably outline what relayers can expect from the SDK IBC implementation

Hmm, strictly speaking, the connection end does not need to store the local connection ID since it is part of the key.

Is there a reason we need to store this in the SDK? If not, let's remove it.

probably convenience, I can take this change on

probably convenience, I can take this change on

Splendid, thanks. Just cleaner to avoiding duplicating data, I think.

For "query all connections" query, the id along ConnectionEnd is useful. For channels there is the IdentifiedChannel struct.

For "query all connections" query, the id along ConnectionEnd is useful. For channels there is the IdentifiedChannel struct.

We can create an analogous IdentifiedConnection, I expect.

Was this page helpful?
0 / 5 - 0 ratings