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 query channel end returns Uninitialized result state when invalid channel/port is provided. #875

Closed
5 tasks
soareschen opened this issue Apr 29, 2021 · 0 comments · Fixed by #923
Closed
5 tasks
Assignees
Labels
O: usability Objective: cause to improve the user experience (UX) and ease using the product
Milestone

Comments

@soareschen
Copy link
Contributor

soareschen commented Apr 29, 2021

Crate

relayer-cli

Summary of Bug

The command hermes query channel end requires the port ID to be specified first, followed by the channel ID. If the argument position is wrong, the command returns a success result with Uninitialized state, instead of reporting failure. This can also happen when any invalid port ID or channel ID is provided.
Note: same issue exists for hermes query connection end when a non-existing connection id is specified.

A success result is as follows:

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

When the argument for port ID and channel ID are interchanged, the following result is returned:

$ hermes query channel end ibc-0 channel-0 transfer
Success: ChannelEnd {
    state: Uninitialized,
    ordering: Unordered,
    remote: Counterparty {
        port_id: PortId(
            "defaultPort",
        ),
        channel_id: None,
    },
    connection_hops: [],
    version: "",
}

@ancazamfir explains that this is because the RPC returns the uninitialized result, while GRPC returns the expected failure result:

I changed the query connection locally to use gRPC and it returns

Error: query error: GRPC error: status: NotFound, message: "rpc error: code = NotFound desc = connection-3: connection not found: key not found", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc"} }

So, because of the inconsistencies between the RPC and gRPC query results, I think we should change all the queries, where possible, to use the gRPC. afaik, only the queries requiring proofs should stay RPC, i don’t think we can yet get proofs from gRPC queries. Also we should be looking at the query height and see if for non-proven queries they are actually used (another thing we cannot do with gRPC)

Version

0.2.0

Steps to Reproduce

The following commands return uninitialized results instead of reporting failure:

hermes query channel end chain-id channel-id port-id
hermes query channel end chain-id {invalid-port} channel-id
hermes query channel end chain-id  port-id {invalid-channel}
hermes query channel end chain-id {invalid-port} {invalid-channel}

Acceptance Criteria

hermes query channel end chain-id {invalid-port} {invalid-channel} should return failure instead of uninitialized result.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@ancazamfir ancazamfir added this to the 05.2021 milestone Apr 29, 2021
@ancazamfir ancazamfir added the O: usability Objective: cause to improve the user experience (UX) and ease using the product label Apr 29, 2021
@ancazamfir ancazamfir self-assigned this May 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O: usability Objective: cause to improve the user experience (UX) and ease using the product
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants