-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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 #10429
Comments
I'm relaying with go-relayer at this moment, but also happens with Hermes
and with TS relayer..
The timeout recalculate issue happens before I send the TX, if you see the
logs you can get the wrong timeout (I canceled the TX and tested with
another)
El lun., 25 oct. 2021 16:43, Anca Zamfir ***@***.***>
escribió:
… Please include the hermes config and version that you are using. Also the
sequence of operations, specifically are you running hermes before you send
the transfers? Or you do hermes start after?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#10429 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4T75TX2OXVXUAUN6ANEJDUIVUHPANCNFSM5GUX7N4Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Similar issue is opened here informalsystems/ibc-rs#1445 as well as cosmos/ibc-go#492 |
Yes, I saw this logs about the future.
In this case when you have a chain with few TX by hour, you experiment the
timeouts.
The way to avoid for me is to setup a script that raise a TX before the
10minutes (default timeout)
El lun., 25 oct. 2021 18:28, Justin Tieri ***@***.***>
escribió:
… Similar issue is opened here informalsystems/ibc-rs#1445
<https://github.com/informalsystems/ibc-rs/issues/1445> as well as
cosmos/ibc-go#492 <cosmos/ibc-go#492>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#10429 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4T75WBZ2XWJ7PLKZVWS73UIWARLANCNFSM5GUX7N4Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
It is possible for a packet to not be timed out when evaluated but the timeout to pass by the it is processed by the chain. In hermes the error should trigger a retry and at that time a timeout should be sent.
We are not aware of this. Could you please open an issue in ibc-rs and provide the block times of the two chains, hermes I also noticed that the packet timeout stamp is |
I will open a issue at ibc-go.
I'm using GoRelayer(last version of Strange Ventures) but I'm suffering
this error from months ago in all the working relayers (go, TS, hermes)
because if you simulate the TX you can see how the timestamp is the same
even when you wait for a minutes before try it again, see the logs in the
first post.
When we use hermes, of course is running in background as service, and
after passing the initial checkings.
El lun., 25 oct. 2021 18:58, Anca Zamfir ***@***.***>
escribió:
… It is possible for a packet to not be timed out when evaluated but the
timeout to pass by the it is processed by the chain. In hermes the error
should trigger a retry and at that time a timeout should be sent.
This causes invalid packets if a valid TX is not sent within 10 minutes
(default value of the timeout).
We are not aware of this. Could you please open an issue in ibc-rs
<https://github.com/informalsystems/ibc-rs/> and provide the block times
of the two chains, hermes config.toml you are using, version and
operation order. Specifically, do you send the packets and then start
hermes? Or is hermes already started?
I also noticed that the packet timeout stamp is 2021-10-25
08:01:52.35098402 +0000 UTC while the packet seems to have been sent at 08:00:40
UTC 2021 which looks like a smaller timeout.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#10429 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4T75WSK3YCM7KAWVZVLR3UIWEB5ANCNFSM5GUX7N4Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Only trying the command and canceling the broadcasting you can see that timestamp is always the same, So, not a relayer issue, I guess |
Opened an issue at IBC 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: