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

Discrepancy between foundry-zksync and zksync-sepolia #403

Closed
2 tasks done
sendra opened this issue May 30, 2024 · 1 comment
Closed
2 tasks done

Discrepancy between foundry-zksync and zksync-sepolia #403

sendra opened this issue May 30, 2024 · 1 comment

Comments

@sendra
Copy link

sendra commented May 30, 2024

Component

Forge

Have you ensured that all of these are up to date?

  • Foundry
  • Foundryup

What version of Foundry are you on?

forge 0.0.2 (1f3160e 2024-05-30T00:22:09.630097000Z)

What command(s) is the bug in?

No response

Operating System

macOS (Apple Silicon)

Describe the bug

Problem:

Trouble debugging why a bridging transaction fails on zksync-sepolia side.

Also a weird value is shown on the View page for L1->L2 transactions, with value: 79,598,458,911,708,134,998 (T)

How to reproduce:

To locally reproduce error, to try and debug, execute:
forge test --match-contract ZkSyncAdapterTest --match-test test_receiveMessage -vvvv
on the code on this branch

This will execute a test that forks zksync-sepolia on the block of the failing transaction. This test calls the same method as the failing tx with the expected aliased caller. It checks that all the on chain configs are correct, previous to the call, and checks that all the expected events and state changes happen after the call (It uses the deployed addresses, without using mocks).

The problem is that the test execution on the fork works as it should, while the execution on the testnet chain doesn't.

This was done using the dev branch of foundry-zksync

@sendra sendra added the T-bug label May 30, 2024
@Karrq
Copy link
Contributor

Karrq commented Jun 5, 2024

This issue was resolved internally by setting a manual gas limit higher than calculated by foundry - we have opened #418 to track this.

Thank you for the report!

@Karrq Karrq closed this as completed Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants