Skip to content
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

Supersim autorelay flakes #291

Open
Tracked by #308
tremarkley opened this issue Dec 3, 2024 · 3 comments
Open
Tracked by #308

Supersim autorelay flakes #291

tremarkley opened this issue Dec 3, 2024 · 3 comments
Assignees
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed unprioritized

Comments

@tremarkley
Copy link
Contributor

Occasionally when messages are relayed using supersim they return the following error:

execution reverted: custom error 0xb7d09497

This signature corresponds to the InvalidTimestamp error when validating the cross chain message inside the CrossL2Inbox: https://github.com/ethereum-optimism/optimism/blob/cbfb97ede9d8ab4da2e3c4ef65ac8e366ad5f422/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol#L192

This is most likely due to a race condition involving different timestamps between two l2s. This is also causing flakes on several of the tests that rely on relaying messages (e.g. TestCrosschainETHTransfer)

@tremarkley tremarkley added bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed unprioritized labels Dec 3, 2024
@s29papi
Copy link
Contributor

s29papi commented Dec 3, 2024

@tremarkley I want to take on this. Appreciate if assigned to me.

@tremarkley
Copy link
Contributor Author

@s29papi assigned to you

@s29papi
Copy link
Contributor

s29papi commented Dec 10, 2024

Hey @tremarkley,

I've been trying to trace back from the error point to identify a good starting point in the code to address this issue, but the nature of the bug has made it quite challenging. However, I am still eager to tackle it.

Regarding your comment about the potential race condition involving different timestamps between the two L2s, I wanted to ask if you think this could be related to the processEventLog function in the interop indexer. I noticed that the source L2 timestamp is passed there, and I'm curious if you believe this could be a contributing factor.

Could you provide more details on where you think this issue might be originating from? I would like to review the relevant code to see if I can spot the problem directly. Any insights you can share would be incredibly helpful in guiding my investigation.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed unprioritized
Projects
None yet
Development

No branches or pull requests

2 participants