-
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
hermes start
crashes on broadcast_tx_commit timeout
#977
Comments
Just saw another version of this with a panic trace I haven't seen before while setting up a channel:
But it seems to recover from this one and completes the handshake ... |
Yes, we discussed it last week and also with the DEX folks. We are going to look at it this week. There is another significant problem with the wrt to fixing this, at least at first look it is not straightforward to me. All our workers are fully blocking and expect a list of events for the messages included in the Tx. Ideally this should happen behind the scenes but i don't think the current setup with the runtime allows this easily. We also need to keep track of the sequence numbers (this doesn't look too bad) so the issues with the seq# mismatch should go away. |
hermes start
will sometimes crash on the following:This error should be pretty easy to recover from since the tx will likely be committed, we're just not waiting long enough. This timeout is configured by the full node as
timeout_broadcast_tx_commit
and defaults to10s
, which isn't even enough for 2 blocks on the hub, but it's also not a parameter we can control. If we timeout, we just need to wait to see when the tx gets included in a block (maybe for this we can have a local timeout).A more robust approach would to use
broascast_tx_sync
(which only waits for the tx to pass into the mempool) and then monitor for the tx to be committed in a block.Here's the full log if it helps:
The text was updated successfully, but these errors were encountered: