-
Notifications
You must be signed in to change notification settings - Fork 410
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
Packet timeout timestamp at IBC is not updated until next TX #611
Comments
I'm relaying with go-relayer at this moment, but also happens with Hermes The timeout recalculate issue happens before I send the TX, if you see the The way to avoid for me is to setup a script that raise a TX before the Other way to avoid is make the TX (even after of 10 minutes) with flag: They Steps to reproduce are easy, don't need to send a TX, you can prepare but cancel the sending, so it don't touch the relayer:
|
Thank you for the bug report. Unless this is a mistake in the IBC specs, please file it on the implementation repo instead. |
Opened in the proper repo: |
Summary of Bug
The field value
timeout_timestamp
is not recalculated properly.Until a new valid TX is generated, the value of the field is not recalculated.
This causes invalid packets if a valid TX is not sent within 10 minutes (default value of the timeout).
Version
From SDK v.0.42.x to v.0.44.x
Tested in
Steps to Reproduce
We get this error on relayer:
I[2021-10-25|08:02:09.671] ✘ [osmosis-1]@{1723868} - msg(0:/ibc.core.client.v1.MsgUpdateClient,1:/ibc.core.channel.v1.MsgRecvPacket) err(channel:14:failed to execute message; message index: 1: receive packet verification failed: block timestamp >= packet timeout timestamp (2021-10-25 08:02:00.472031016 +0000 UTC >= 2021-10-25 08:01:52.35098402 +0000 UTC): packet timeout)
The same for
osmosisd
The TX timeout value was 14 minutes in the past
E[2021-10-25|08:12:10.254] - [bitcanna-1] -> err(rpc error: code = InvalidArgument desc = failed to execute message; message index: 1: receive packet verification failed: block timestamp >= packet timeout timestamp (2021-10-25 08:12:03.465933869 +0000 UTC >= 2021-10-25 07:57:10.21737206 +0000 UTC): packet timeout: invalid request)
For Admin Use
The text was updated successfully, but these errors were encountered: