`CrossChainMessenger.getMessageReceipt` function doesn't set lower limit in event query

[palango]

Describe the bug

The CrossChainMessenger.getMessageReceipt function doesn't provide the correct fromBlock parameter to the contract.queryFilter function. So running it after the receipt is available won't be returned a second time.

To Reproduce

1. Create a L1->L2 message
2. Run the message-relayer on that tx
3. After this finishes, run it a second time. It will block here: https://github.com/ethereum-optimism/optimism/blob/13a9e9bdbdc703a2936506600173609c76364cca/packages/message-relayer/src/service.ts#L179

Expected behavior

Running a second time should work.

Additional context

My understanding is that the event query should use the block number of the transaction as the lower block limit. With that the event would be found.

[istankovic]

Bump.

[smartcontracts]

Hi, sorry for the delay here. I am the primary maintainer of the message-relayer and I have been on vacation for the past 3 weeks. What is the exact behavior you're seeing? It simply hangs without executing any further? Lower bound should be set to block zero by if fromBlock is not provided, so this should work in theory. Are you sure the relayer is blocking on the specific line you listed?

[smartcontracts]

Also, are you running this against a live network? Or on the local devnet? On Bedrock or Legacy?

[istankovic]

Hey @smartcontracts, thanks for getting back to us.

This turned out to be an issue on our end. So I think this can be closed now.

During the course of analysing this, we discovered that this.state.messenger.finalizeMessage threw an error:

Error: cannot estimate gas; transaction may fail or may require manual gas limit [ See: https://links.ethers.org/v5-errors-UNPREDICTABLE_GAS_LIMIT ] (error={"reason":"execution reverted","code":"UNPREDICTABLE_GAS_LIMIT","method":"estimateGas

This happens on chain ID 10, mainnet Optimism, with a message that has already been finalized and relayed successfully once. Is there a way to determine the underlying reason for the revert?

[smartcontracts]

Generally speaking "cannot estimate gas; transaction may fail or may require manual gas limit" means that the transaction is always failing and there is no gas limit that would make the transaction work. It's most likely that you are calling a contract that is always reverting. You can try to explicitly set the gas limit using the overrides parameter to execute the transaction and then see what the revert reason is when the transaction is executed. Of course, this will cost ETH on mainnet.

[istankovic]

Generally speaking "cannot estimate gas; transaction may fail or may require manual gas limit" means that the transaction is always failing and there is no gas limit that would make the transaction work. It's most likely that you are calling a contract that is always reverting. You can try to explicitly set the gas limit using the overrides parameter to execute the transaction and then see what the revert reason is when the transaction is executed. Of course, this will cost ETH on mainnet.

Thanks for the answer.

By the way, feel free to close this issue, I consider this resolved.

[smartcontracts]

SGTM, closing!