Possible error related to timeout about gon-evidence HOT 6 CLOSED

The main problem in this case was that the timeout transaction had not been picked up and committed back to Juno - so it appeared to be gone.
Running the relayer on that channel fixed the problem.

I think the reason the height was wrong here (and therefore caused a timeout) was because no relayer was running and updating the client. When the client is not updated, the height will be wrong. But the worst that should happen is a timeout. And that is also what happened.

So all in all, pretty sure this is just a lack of relayers running

from gon-evidence.

the solution is to use timestamp, or timeout-height but taking as base the latest height from remote chain.

from gon-evidence.

the solution is to use timestamp, or timeout-height but taking as base the latest height from remote chain.

I didn't need a solution.
I did not understand the very essence of the error and the reason for its occurrence.

from gon-evidence.

@Exclusive048 That error does not come from the transaction, you should check in GoN cli repo (third party)

from gon-evidence.

@giansalex , In this case, I suggest participants not to use the service, so as not to waste their time.

from gon-evidence.

@giansalex , In this case, I suggest participants not to use the service, so as not to waste their time.

That won't help much, as the main problem here is that the channel is filled up with 350,000 transactions. The cli works just fine, but transactions are going to time out in most cases anyway.

In any case: the CLI has already been updated to be more lenient in the IBC timeout, but it won't help in the spammed channels.

from gon-evidence.