mysterious test failures, inability to check changes in state

[0xBrian]

mysterious test failures, inability to check changes in state

[Karrq]

Thanks for the report!
Could you let us know exactly the error you are getting? Is is the last assertion that fails or is there some other error message?

[0xBrian]

It's just the assertion that doesn't pass, no error message. I think test1 and test2 should either both pass, or both fail. Thanks.

[Karrq]

Hey @0xBrian, I investigated the issue. Thanks for the reproducible example, it was really helpful!

I actually tried fetching the source and luckily the contract was verified on the explorer so I could take a look at how it worked, and noticed that the DIGEST is computed using a few items from the contract state, but also the msg.sender.

Unfortunately, the answer to your issue is rather bland: prank simply doesn't set the msg.sender for nested calls!
So, in test2, the msg.sender would end up being the address where Blah was deployed, and not MINER, as it would be in the test1.

I hope this helps!

[0xBrian]

OK, thank you for investigating. We figured it was something like that. But does it work this way in normal Foundry, or is it something related to the changes required for ZKSync? To me it seems like this behavior would prevent anyone from writing realistic tests.

[Karrq]

Yes, that's intended foundry behaviour, we can also see this in the test suite here.

What we do require for ZKSync is that any contract running inside zkVM isn't able to use cheatcodes (in this case Blah), but you can work around that by disabling zkVM before the call to the external contract, run your cheatcodes there, and re-enable zkVM afterwards.

For example:

vm.zkVm(false);
blah.doit(...);

and inside doit:

vm.zkVm(true); //here or after prank is fine either way
// the important part is that `doit` isn't run inside zkVM
vm.prank(MINER);
...

As far as realistic test, I'm not sure I understand what you mean. If instead of Blah you had another contract, on chain, which handled the calls to MINING_CONTRACT_ADDRESS somehow, shouldn't you be calling tha contract instead then? And if instead it was some other kind of program off chain, wouldn't that basically be Test1?

You can always create other functions in the Test1 contract to group functionality, and as long as it's not prefixed with test (or a few others like invariant) then it won't be executed as a standalone test.

I'll go ahead and close the issue since we clarified it's intended behaviour, but if you have any more questions you can just comment here on the issue and I'll still reply :)