vm.getCode doesn't find artifacts by name

[martinvol]

Component

Forge

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

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (1281421 2024-04-05T00:21:15.963758000Z)

What command(s) is the bug in?

forge script

Operating System

macOS (Apple Silicon)

Describe the bug

In a project I have a contract called ProxyFactory. It gets compiled and its artifacts written to out/ProxyFactory.sol/ProxyFactory.json.

However vm.getCode("ProxyFactory") fails with

    ├─ [0] VM::getCode("ProxyFactory.sol") [staticcall]
    │   └─ ← [Revert] No matching artifact found
    └─ ← [Revert] No matching artifact found

But the following call does work: vm.getCode("./out/ProxyFactory.sol/ProxyFactory.json")

I've started noticing this issue since upgrading from version forge 0.2.0 (7b45265 2023-11-21T00:18:30.267248000Z) to forge 0.2.0 (1281421 2024-04-05T00:21:15.963758000Z).

I think this issue is highly related to #6572, but as the the error messages don't match I though it was worth opening a different one.

[klkvr]

@martinvol we've inroduced smarter compilation for forge test in #7334 which does not recompile entire project when running tests.

Because of that, we can't anymore guarantee that all artifacts would be fresh when running tests and we've also inroduced additional vaildation of getCode/getDeployedCode calls - #7334 (comment)

Can you confirm that this issue occurs on running a forge test without filters and that none of your test contracts import ProxyFactory.sol source directly? If so, you can simply add an import of that file to any of the test contracts and getCode should be working normally.

If you have import of that file somewhere in tests then this is a bug, and would be great if you could provide some kind of repro

[klkvr]

After a second thought I think a better UX would be to always recompile all files under src when running tests, will create a PR for that soon

[martinvol]

Oh, ftr this happens even if I run `forge build` first. Is that expected? As a follow up, the artifact is indeed in the out folder (see the code that does work), but the script somehow can't find it at least the full path is provided. This is triggered by `forge script` and can guarantee the contract that's failing is not imported anywhere. I think I hit an edge case there, because I can't import the file because my script is in 0.8 but I'm working with a legacy contract that is in 0.5, so getCode is the only way I know how to deploy it.

…

On Fri, Apr 5, 2024, 19:40 Arsenii Kulikov ***@***.***> wrote: After a second thought I think a better UX would be to always recompile all files under src when running tests, will create a PR for that soon — Reply to this email directly, view it on GitHub <#7569 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFKNK5Z7JFZAVM33PXZ3VLY33O2LAVCNFSM6AAAAABFZNAMTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBQGMZDAMBYGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[klkvr]

ah, I see, yeah in that case you can't have it imported anywhere because your contracts wouldn't compile otherwise.

if this contract is in src, then #7572 should resolve this for you

otherwise, you can either move it to src or enable unchecked_cheatcode_artifacts

[martinvol]

Wow Tha was fast