Calling hardhat_setStorageAt after eth_getStorageAt doesn't work when forking

[Rubilmax]

Minimal reproducible example

Using hardhat 2.22.5 (EDR ^0.4.0), the following code rejects with "Contract with code hash 0xaee43571f51ad4922c41ab126fb98a76934d579c76f54b9e393ade09aad21646 does not exist.":

    await getStorageAt(
      "0xbe9895146f7af43049ca1c1ae358b0541ea49704",
      "0x4f039c94bc7b6c8e7867b9fbd2890a637837fea1c829f434a649c572b15b2969",
    );

    await setStorageAt(
      "0xbe9895146f7af43049ca1c1ae358b0541ea49704",
      "0x4f039c94bc7b6c8e7867b9fbd2890a637837fea1c829f434a649c572b15b2969",
      "0x0000000000000000000000000000000000000000000000000000000000000001",
    );

While the following one does not:

    await setStorageAt(
      "0xbe9895146f7af43049ca1c1ae358b0541ea49704",
      "0x4f039c94bc7b6c8e7867b9fbd2890a637837fea1c829f434a649c572b15b2969",
      "0x0000000000000000000000000000000000000000000000000000000000000001",
    );

    await getStorageAt(
      "0xbe9895146f7af43049ca1c1ae358b0541ea49704",
      "0x4f039c94bc7b6c8e7867b9fbd2890a637837fea1c829f434a649c572b15b2969",
    );

In other words, inverting the order of requests eth_getStorageAt and hardhat_setStorageAt changes the behavior of the EDR, while it should not (both should not reject)

[fvictorio]

I can't reproduce this. @Rubilmax could you please create and share a minimal reproducible example?

[Rubilmax]

Sorry, update the description because I mixed up addresses.

Here is a reproducible example: https://github.com/Rubilmax/edr-setStorageAt-issue

Configure a rpc URL in the environment variable and run yarn test

[Rubilmax]

Quick notes:

• 0xbe9895146f7af43049ca1c1ae358b0541ea49704 corresponds to cbETH on mainnet
• 0xbe9895146f7af43049ca1c1ae358b0541ea49703, which was the original address in this issue's description, doesn't revert (and it corresponds to an unclaimed EOA)
• Maybe related to hardhat_setBalance on contracts is reverting with "Contract with code hash 0x... does not exist" #336?

[fvictorio]

Thanks a lot @Rubilmax, that's a great repro. Confirmed that this is happening and important.

Some more info for ourselves:

1. For some reason, doing an eth_getCode call with that address before the calls makes the problem go away.
2. This doesn't seem to be related to these calls being done in the forked block. Mining a block before the calls doesn't have an effect.

[Rubilmax]

Thanks a lot for the hot fix, will do this while a proper fix is published to the EDR

[Wodann]

I discovered the culprit and fixed the bug. Thank you for the detailed reproduction steps!

We'll release a new patch version of EDR as soon as possible.

[fvictorio]

We've released EDR v0.4.1 with a fix for this issue.

To upgrade to the latest EDR version immediately, you can remove your node_modules directory and npm/yarn/pnpm lock file and reinstall your dependencies. Otherwise you can wait for the next Hardhat release which will automatically use the latest EDR version.

You can verify that you’re using the latest version of EDR by running the following command: npm ls @nomicfoundation/edr.