ethers middleware short term fixes #5107
Assignees
Labels
Comments
This was referenced Jan 6, 2025
github-merge-queue bot
pushed a commit
that referenced
this issue
Jan 13, 2025
### Description Uses the short-term fixes described in this [design doc](https://www.notion.so/hyperlanexyz/State-of-EVM-provider-middleware-16c6d35200d680d8a6b5f0d32cd8c66b?pvs=4) and implemented in hyperlane-xyz/ethers-rs#23 These fixes are expected to make the relayer self-recover from nonce gaps. An expected drawback is that tx hashes are dropped more often due to the nonce manager resyncing to nonces that end up being too low by 1, which can slow down submissions. After 12h of testing, any submit queue spikes were only 1 min long and the biggest one had 7 messages - so short enough not to trigger the "rising submit queue" alert which stays pending for 6min: https://abacusworks.grafana.net/alerting/de6hwplr7eakgc ### Drive-by changes - Removes verbosity from a bunch of logs (we had `HyperlaneMessage` in a single log occur 6-7 times, but wasn't noticeable in `span`s because it was originating from args named `message` which have a clash with inner workings of the `tracing` lib) - rewords some logs because they were misleading ### Related issues Fixes: #5107 ### Backward compatibility Yes ### Testing E2E with a gas escalator that randomly dropped every other tx - the nonce manager was able to recover but was slower to submit. Then evaluated on RC for 12h as described above.
fmorency
pushed a commit
to fmorency/hyperlane-agents
that referenced
this issue
Feb 20, 2025
### Description Uses the short-term fixes described in this [design doc](https://www.notion.so/hyperlanexyz/State-of-EVM-provider-middleware-16c6d35200d680d8a6b5f0d32cd8c66b?pvs=4) and implemented in hyperlane-xyz/ethers-rs#23 These fixes are expected to make the relayer self-recover from nonce gaps. An expected drawback is that tx hashes are dropped more often due to the nonce manager resyncing to nonces that end up being too low by 1, which can slow down submissions. After 12h of testing, any submit queue spikes were only 1 min long and the biggest one had 7 messages - so short enough not to trigger the "rising submit queue" alert which stays pending for 6min: https://abacusworks.grafana.net/alerting/de6hwplr7eakgc ### Drive-by changes - Removes verbosity from a bunch of logs (we had `HyperlaneMessage` in a single log occur 6-7 times, but wasn't noticeable in `span`s because it was originating from args named `message` which have a clash with inner workings of the `tracing` lib) - rewords some logs because they were misleading ### Related issues Fixes: hyperlane-xyz/hyperlane-monorepo#5107 ### Backward compatibility Yes ### Testing E2E with a gas escalator that randomly dropped every other tx - the nonce manager was able to recover but was slower to submit. Then evaluated on RC for 12h as described above.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#5100
The text was updated successfully, but these errors were encountered: