hyperlane-monorepo

The home for Hyperlane core contracts, sdk packages, and other infrastructure

blockchain hyperlane interchain monorepo

History

Daniel Savu 97588b6fc1 fix(relayer): don't submit reverting messages in batches (#4169 ) ### Description Depends on https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/4159 Some messages in a Multicall would revert because previous messages would invalidate them temporarily. The IGP allowance of those messages would be deducted, and if this happened more than once, those messages would become stuck. This PR fixes those unnecesary spends on reverting `process` txs by using `.call()` to simulate the outcome of a Multicall tx. Reverting messages are removed from the batch and submitted serially, and if the batch is only left with one non-reverting message, even that one is submitted serially (rather than through a batch of one message). Messages that did get submitted have their igp allowance deducted and status updated in `update_sent_ops_state`. ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues - Fixes https://github.com/hyperlane-xyz/issues/issues/1294 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing Tested by manually setting the result of `call` to failed for all messages, to see if they are submitted serially. In prod, we can track the `Submitted transaction batch` log, which now includes any excluded messages from the batch.	4 months ago
..
src	fix(relayer): don't submit reverting messages in batches (#4169 )	4 months ago
Cargo.toml	Rust updates (#2619 )	1 year ago

fix(relayer): don't submit reverting messages in batches (#4169 )

### Description

Depends on https://github.com/hyperlane-xyz/hyperlane-monorepo/pull/4159

Some messages in a Multicall would revert because previous messages
would invalidate them temporarily. The IGP allowance of those messages
would be deducted, and if this happened more than once, those messages
would become stuck.

This PR fixes those unnecesary spends on reverting `process` txs by
using `.call()` to simulate the outcome of a Multicall tx. Reverting
messages are removed from the batch and submitted serially, and if the
batch is only left with one non-reverting message, even that one is
submitted serially (rather than through a batch of one message).

Messages that did get submitted have their igp allowance deducted and
status updated in `update_sent_ops_state`.

### Drive-by changes

<!--
Are there any minor or drive-by changes also included?
-->

### Related issues

- Fixes https://github.com/hyperlane-xyz/issues/issues/1294
### Backward compatibility

<!--
Are these changes backward compatible? Are there any infrastructure
implications, e.g. changes that would prohibit deploying older commits
using this infra tooling?

Yes/No
-->

### Testing

Tested by manually setting the result of `call` to failed for all
messages, to see if they are submitted serially. In prod, we can track
the `Submitted transaction batch` log, which now includes any excluded
messages from the batch.

4 months ago

src

fix(relayer): don't submit reverting messages in batches (#4169 )

4 months ago

Cargo.toml

Rust updates (#2619 )

1 year ago