Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hermes channel create creates un-opened channel #1064

Closed
5 of 6 tasks
adizere opened this issue Jun 8, 2021 · 0 comments · Fixed by #1066
Closed
5 of 6 tasks

Hermes channel create creates un-opened channel #1064

adizere opened this issue Jun 8, 2021 · 0 comments · Fixed by #1066
Assignees
Labels
A: bug Admin: something isn't working I: logic Internal: related to the relaying logic
Milestone

Comments

@adizere
Copy link
Member

adizere commented Jun 8, 2021

Crate

ibc-relayer

Summary of Bug

The command hermes create channel create a new channel, but only one end of the channel is Open, while the other end is TryOpen. In other words, Hermes omits sending the final OpenConfirm step to side 'b' of the channel.

Using a default config.toml from current master:

> hermes create channel ibc-0 ibc-1 --port-a transfer --port-b transfer
# ...
# the last step, before returning success is as OpenAck (instead of OpenConfirm):
# 
Jun 08 13:42:33.953  INFO ibc_relayer::channel: done ibc-0 => OpenAckChannel(
    OpenAck(
        Attributes {
            height: Height {
                revision: 0,
                height: 244,
            },
            port_id: PortId(
                "transfer",
            ),
            channel_id: Some(
                ChannelId(
                    "channel-0",
                ),
            ),
            connection_id: ConnectionId(
                "connection-0",
            ),
            counterparty_port_id: PortId(
                "transfer",
            ),
            counterparty_channel_id: Some(
                ChannelId(
                    "channel-0",
                ),
            ),
        },
    ),
)

Querying the channel ends shows that the channel is open only on one side..

> hermes query channel end ibc-0 transfer channel-0
Success: ChannelEnd {
    state: Open,                <<<<<<-------- This is Open
    ordering: Unordered,
    remote: Counterparty {
        port_id: PortId(
            "transfer",
        ),
        channel_id: Some(
            ChannelId(
                "channel-0",
            ),
        ),
    },
    connection_hops: [
        ConnectionId(
            "connection-0",
        ),
    ],
    version: "ics20-1",
}
> hermes query channel end ibc-1 transfer channel-0
Success: ChannelEnd {
    state: TryOpen,                <<<<<<-------- Should be Open
    ordering: Unordered,
    remote: Counterparty {
        port_id: PortId(
            "transfer",
        ),
        channel_id: Some(
            ChannelId(
                "channel-0",
            ),
        ),
    },
    connection_hops: [
        ConnectionId(
            "connection-0",
        ),
    ],
    version: "ics20-1",
}

Version

2b84667

The bug is recent, since we didn't observe it in v0.4.0. I did a quick check of this bug against commit dc6e840, and the bug does not manifest there. So the bug probably originates from recent changes around the channel, e.g., c375c71.

Steps to Reproduce

> hermes create channel ibc-0 ibc-1 --port-a transfer --port-b transfer
> hermes query channel end ibc-0 transfer channel-0
> hermes query channel end ibc-1 transfer channel-0

Acceptance Criteria

  • the channel ends on both sides should be in state Open if command hermes create channel ends with a Success status

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@adizere adizere added A: bug Admin: something isn't working I: logic Internal: related to the relaying logic labels Jun 8, 2021
@adizere adizere added this to the 06.2021 milestone Jun 8, 2021
@adizere adizere self-assigned this Jun 8, 2021
adizere added a commit that referenced this issue Jun 8, 2021
adizere added a commit that referenced this issue Jun 15, 2021
…te` (#1066)

* Countermeasure that fixes #1038

* Tentative fix for #1064

* Better fix for the impersonation problem

* Better log message. Handle (TryOpen, Init) case

* Changelog

* Better error, added doc comment, less clones.

* Clarify the intent of method do_chan_open_ack_confirm_step

* Removed some unnecessary clones

* Moved check_channel_counterparty to chain::counterparty

* Fully specified error in case of failure in check_channel_counterparty

* Used port+channel instead of socket

* Fix small typo in error variant

* Removed chan counterparty verification in ft-transfer.

Co-authored-by: Anca Zamfir <zamfiranca@gmail.com>
hu55a1n1 pushed a commit to hu55a1n1/hermes that referenced this issue Sep 13, 2022
…te` (informalsystems#1066)

* Countermeasure that fixes informalsystems#1038

* Tentative fix for informalsystems#1064

* Better fix for the impersonation problem

* Better log message. Handle (TryOpen, Init) case

* Changelog

* Better error, added doc comment, less clones.

* Clarify the intent of method do_chan_open_ack_confirm_step

* Removed some unnecessary clones

* Moved check_channel_counterparty to chain::counterparty

* Fully specified error in case of failure in check_channel_counterparty

* Used port+channel instead of socket

* Fix small typo in error variant

* Removed chan counterparty verification in ft-transfer.

Co-authored-by: Anca Zamfir <zamfiranca@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A: bug Admin: something isn't working I: logic Internal: related to the relaying logic
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant