L1 to L2 transaction can run out of gas and never emit FailedRelayMessage event

[K-Ho]

Is your feature request related to a problem? Please describe. Currently, if a deposit (or any L1->L2 message) reverts when being completed on L2, the Watcher won't pick it up. This can be confusing to developers to whether the l1->L2 message is reverting or if it's the underlying network having issues.

Describe the solution you'd like The solution that I have in mind would touch multiple pieces. Ideally we can guarantee that if a deposit is going to fail, that we still hit this event and can have the watcher listen for FailedRelayMessage events: https://github.com/ethereum-optimism/optimism/blob/55ee461e3f0a051f23267b2b14f8e2fb9ffdc1c4/packages/contracts/contracts/optimistic-ethereum/OVM/bridge/messaging/OVM_L2CrossDomainMessenger.sol#L105 However, this would not work if all gas is consumed before reaching that line. To combat that, you would need to also add:

1. enforce that the gasLimit for an L2 message is high enough to reach through to that event no matter what: https://github.com/ethereum-optimism/optimism/blob/55ee461e3f0a051f23267b2b14f8e2fb9ffdc1c4/packages/contracts/contracts/optimistic-ethereum/OVM/chain/OVM_CanonicalTransactionChain.sol#L276
2. This messenger call (https://github.com/ethereum-optimism/optimism/blob/55ee461e3f0a051f23267b2b14f8e2fb9ffdc1c4/packages/contracts/contracts/optimistic-ethereum/OVM/bridge/messaging/OVM_L2CrossDomainMessenger.sol#L96) should be passed gasUsed - AMOUNT, where AMOUNT guarantees that there is still enough gas to execute the setting of the XDomainMessageSender and emitting of the event.

Describe alternatives you've considered An alternative would be to parse all transactions and look at calldata in the watcher to match L1 txs with their corresponding L2 tx even if it's a reverting tx, but this would likely be very inefficient.

[K-Ho]

The watcher part of this issue has been fixed with https://github.com/ethereum-optimism/optimism/commit/f091e8677f152dcae07064982421e35e290915f1, but it is still the case that a tx could run out of gas and never reach the FailedRelayMessage event (second half of this issue)

[snario]

Watcher already listens to the event as per https://github.com/ethereum-optimism/optimism/pull/937. Renamed issue to refer to dealing with gas issue.

[smartcontracts]

Transferring over to specs repo. Solution would be to enforce a minimum amount of gas for deposits. I believe we should specify this for inclusion in Bedrock.

[norswap]

Relevant related discussion: https://github.com/ethereum-optimism/optimistic-specs/discussions/112#discussioncomment-2446359

Current plan is to by default route L1-L2 transactions through a "messenger" (name might need changing) on L2, which would implement a replay logic. Every transaction would have enough "guaranteed gas" to be able to register for replay.