-
Notifications
You must be signed in to change notification settings - Fork 329
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
Four IBC packets are stuck on Osmosis <> Evmos channel #2453
Comments
Yes we should be able to use |
I have some diffs in
Works on a local setup. But couldn't run it on osmosis because the rpc nodes in the hermes config included in this issue are far and slow and hermes cannot finish the
|
One more note, in case someone has better RPC nodes and is able to run these CLIs. |
The alternative is to craft the four packets and build the |
Summary of Bug
There are 4 stuck packets in the Evmos <> Osmosis channel.
https://www.mintscan.io/osmosis/relayers/channel-204
The channel ends are summarized below.
hermes --config ~/.hermes/evmos.toml query channel ends --chain osmosis-1 --port transfer --channel channel-204
The packets were created ~1 month ago and have the following sequence numbers.
hermes --config ~/.hermes/evmos.toml query packet pending --chain osmosis-1 --port transfer --channel channel-204
Two of the four transactions:
Since these packets have been stuck, plenty of traffic went through that same channel. For reference, the sequence number of the last packet (currently) on
osmosis-1:channel-204
that was successfully received on evmos and then acknowledged back on osmosis-1 is 187,791.Why are these packets stuck?
If we try to clear those packets, we see the following:
So Hermes is able to identify the 4 packets, but does not find packet data "pulled packet data for 0 events". In more details:
/tx_search
endpoint) returns the event result with log "account sequence mismatch, expected 130, got 129"4'721'268
4'713'069
It is unclear why are there 2 separate heights associated with this transaction hash. But we were able to confirm from the Tendermint team that:
Reference for the Tendermint issue: tendermint/tendermint#8945
The full output is very large (part of output is here), but the packet data can be seen there.
The problem is that it seems the
tx_search
endpoint is unable to reach that packet data. So far, we tried two approaches:= 4713069
(height specification) versus<= 4713070
versus versus eliminating all fields identifying the packet and keeping onlysend_packet.packet_sequence=127044
let query: Query = "tx.height=4713069 AND send_packet.packet_sequence=127044".parse().unwrap();
) instead of building it viaQuery::eq
interface.The typical outcome is we find no response.
If we are more loose in the way we specify the query, we find the packet data is more recent (from block::Height(4721268)), which includes "account sequence mismatch" error and the relayer is unable to use.
hermes --config ~/.hermes/evmos.toml query packet pending --chain osmosis-1 --port transfer --channel channel-204
For further investigation, we need help from someone who understands the difference between the Tendermint
tx_search
andblock_results
API, and if the relayer is able to use the latter for reconstructing packet data & proofs to be able to clear this channel.For developers:
https://gist.github.com/adizere/bdc8655c2802d683f223fb4a36d83a43
Acceptance Criteria
Note: This is a IBC-wide problem, not specific to ibc-rs/Hermes. The relayer should be able to fix it, however. A large chunk of this investigation is due to Charly and coldchain.
For Admin Use
The text was updated successfully, but these errors were encountered: