Open minaminao opened 1 year ago
Right, this is actually not necessarily a bug, but rather a footgun—the msg.sender is being reset to ContractTest
because the call depth where it was set has exited, but technically there is a running prank at the test level. How should we handle this @mds1 ? We have two options here i believe:
vm.startPrank
at a different depth from where it was set (i can see use cases for this though)Fwiw, I found this when I used prank
in a Huff/Vyper deployer contract (at a different depth). foundry-huff uses the same method: https://github.com/huff-language/foundry-huff/blob/bcac40d5b0950588b30cdf24dff25df080007295/src/HuffConfig.sol#L217 (this uses prank
, not startPrank
though)
Turning this into a feature request of adding a stack
system so pranks can be restored at earlier call depths as suggested by @Evalir
Component
Forge
Have you ensured that all of these are up to date?
What version of Foundry are you on?
forge 0.2.0 (ca67d15 2023-08-01T22:03:12.511500000Z)
What command(s) is the bug in?
forge test
Operating System
macOS (Intel)
Describe the bug
msg.sender
set usingstartPrank
in another contract is wrongThe bug reported in #5515 was fixed in #5520 (thanks for the quick fix), but this is not a complete fix.
Using
startPrank
instead of the bannedprank
still has the bug.The following test
outputs
In
Contract::f()
,VM::startPrank(player: [0x44E97aF4418b7a17AABD8090bEA0A471a366305C])
is execute, but the nextmsg.sender
isContractTest
, notplayer
.Full source: https://github.com/minaminao/foundry-bug-reports/tree/main/2023-08-broken-prank-2