-
Notifications
You must be signed in to change notification settings - Fork 350
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
Packets stuck due to overflowing Timeout #1442
Comments
I think that Hermes was not finding the correct connection. My instance reported that bcna's connection on osmo was
I was able to resolve this (network part of the issue) by manually configuring client, connection, and channel in the go relayer. |
Thank you Raul, Jacob for the thorough details on this issue! It seems that one of the packets has a timeout set to a very large value. I did some preliminary debugging and found the largest value that Hermes can accept without croaking is We'll need access to a bitcanna-1 full node to be able to recreate the problem and fix it. @RaulBernal would you mind sharing with us the Hermes config.toml, so we can access the same full node as in your setup? You can reach me at |
This seems to be a different issue not directly linked to the packet timeout overflowing, maybe we should track this in its own issue? @RaulBernal If you agree with that assessment, would you be so kind as to open another issue for the connection not being found? |
Ok, by the moment, we can focus on the timeout issue. |
Yes it is, we build the TX using cosmjs javascript lib. And we was, by error, "tricking" with that |
You can rise a bitcanna node in seconds with this script:
|
Thanks Raul! There's a hiccup in connecting to the seed/persistent nodes, any thoughts?
ps. I left a comment here BitCannaCommunity/cosmos-statesync_client@92e1899#r57860910 |
Thanks for ping me, the 2 StateSync Servers are restarted. I can't config them as SEED servers so, when their tables are full, I need to restart them manually, is a limitation of StateSync... Ideally this servers should be Seed servers too. Anyway you can bootstrap now:
|
I can reproduce this locally:
|
Some updates
I think we'll just go ahead and reproduce using Anca's solution, though it would be ideal if we still find the offending blockchain packet and confirm that the overflow is from there (we're 99% sure it is). |
Thanks for your support, awesome job there!! |
Hi Raul, We have a candidate solution in PR #1458 -- namely this dev branch. If you could run Hermes from that branch and provide us feedback that would be outstanding! Let us know if you encounter difficulties running it. |
Of course we will do, thanks |
And channels appears to be up:
&
|
The channel in question in this error message is a Rust channel for cross-thread communication not an IBC channel. The Rust channel gets closed/disconnected after the overflow happens, because the latter crashes the underlying thread associated with that chain, so the relayer cannot send requests to that thread anymore, hence the error. |
Apologies for the back-and-forth, Raul! The PR you tested with did not solve the problem completely. I think we have a more stable solution now. If you would kindly run again with the same branch https://github.com/informalsystems/ibc-rs/tree/adi/1442_debug we'd appreciate your feedback again! |
Ok, testing the new development in a It relay the stucked packets :) well done!
Making a new test in two testnets using Hermes (Go-Relayer relay the packets, so no SDK bug) Hermes was able to relay the stucked packets, so with the new version the packets were relayed:
And if we perform a injection of a bad IBC packet is relayed perfeclty:
|
It's weird but I try to send a packet to the pathed channel and doesn't being relayed:
|
Same for testnet:
|
Last test from Testnets with a new clean channel seems good:
|
Great to hear, thanks for the patience and perseverence with testing this Raul! |
Crate
hermes relayer
Summary of Bug
Pending packets are stucked, can't be relayed
Another logs:
This error is in bucle in the relayer log:
hermes 0.7.3+5d53e52 (binary download).
chain SDK v.0.44.1 / tendermint v.0.34.13
Steps to Reproduce
The stacked packets are there.. stacked in the Osmosis chain.
You can see at logs. To get the panic error:
Info of the client/connection/channel/path:
The healthy check:
Connection:
unreceived-acks
Acceptance Criteria
The relaying of the packets
For Admin Use
The text was updated successfully, but these errors were encountered: