-
Notifications
You must be signed in to change notification settings - Fork 352
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
CLI create channel
can fail and spam with unused clients/connections
#1421
Comments
If the |
Hmm you're right, I hadn't thought of that! What would you recommend as an alternative to the |
It sounds like we want to introduce something akin to rate limiting when it comes to these commands such that subsequent executions of the same command within the cooldown period are ignored. |
One more data point I got today wrt our
The way I interpret this is as another signal that |
From today's meeting notes: we will try the following approach (instead of
|
Currently the command can be run in this way:
If the |
Yes. I think we want to change the default invocation from:
to
In other words, if the users wants fresh new clients and connection, they would need to invoke the command differently:
So the presence of
WDYT? |
Crate
ibc-relayer-cli
Summary of problem
This problem is from a conversation with a relayer operator. Ref:
https://twitter.com/gadikian/status/1445306915211251718
The issue documented here appears as a consequence of:
create channel
commandMore concretely, if a user runs
create channel
and notices a failure, then the first instinct is to callcreate channel
again, and again, and again. This can lead to a "spam-attack" of creating many apparently useless clients (and sometimes also connections, depending when the failure happens). The problem appears in particular for production chains, where Hermes is unable to find confirmations within the preconfiguredrpc_timeout = 10s
time (or even longer)https://github.com/informalsystems/ibc-rs/blob/61cd02d1de296e6ab09df30f1f88bb7c8f8cfa33/config.toml#L91
Diagnostic
This is not exactly a Hermes bug. Documenting it here so we can learn from how our users understand the CLIs and how we can improve them.
The problem is rather a combination of multiple circumstance: unintuitive UI, lack of clear logging in the error case for
create channel
, abusing this CLI, and Hermes giving up too easily with confirming tx-es for mainnets.Proposed solution
I think the solution is to introduce an additional parameter to
create channel
e.g., the option[--fresh]
which is required and users have to specify it when they want fresh new clients and connections underlying their new channel. It's very possible that the CLI will continue to be misused otherwise.More importantly: In addition we should consider making Hermes more stubborn when executing CLIs as critical as
create channel
orcreate connection
orcreate client
. These CLIs can sometimes fail even on testnets (with a timeout of 5s) and we recently increased that timeout (#1385) to avoid this issue. It would make sense to make Hermes either:a. retry for a couple of minutes (hardcoded is fine) to find tx confirmations before giving up,
b. explicitly log and inform the user that
rpc_timeout
may be too small or these was an unknown problem (gas prices or fees can also affect this)Version
0.7.3
Steps to Reproduce
hermes create channel juno-1 osmosis-1 --port-a transfer --port-b transfer
Acceptance Criteria
--fresh
flag forcreate
CLIscreate
CLIs with respect to timing out confirmationsrpc_timeout
parameter for non-start
CLIs, so that Hermes is more stubborn when creating clients, channels, connections, etc.For Admin Use
The text was updated successfully, but these errors were encountered: