changePrank fails with No prank in progress to stop

[grandizzy]

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 (f05fdd8 2023-04-27T00:04:10.201981651Z)

What command(s) is the bug in?

No response

Operating System

Linux

Describe the bug

changePrank with no prank started used to work and was properly changing prank before enforcing it in #4827 (8973b2b)
For backwards compatibility reasons, can we have the changePrank exempted from this new check? (test works OK if foundryup -v nightly-dedc31eed0683764ae542b9b575c21f6bd2a5c60)

pragma solidity 0.8.14;

import '@std/Test.sol';
import '@std/Vm.sol';

contract SampleTest is Test {

    address bob;
    address alice;

    function setUp() external {
        bob = makeAddr("bob");
        alice = makeAddr("alice");

        vm.prank(bob);
    }

    function test_sample() external {
        changePrank(alice);
    }

}

Running 1 test for tests/forge/SampleTest.t.sol:SampleTest
[FAIL. Reason: No prank in progress to stop] test_sample() (gas: 5191)
Test result: FAILED. 0 passed; 1 failed; finished in 613.35µs

[PaulRBerg]

changePrank with no prank started used to work

This should never have been the case. See #4779. Are you absolutely sure that you didn't have a startPrank somewhere in your code base?

Cc @mds1.

[grandizzy]

changePrank with no prank started used to work

This should never have been the case. See #4779. Are you absolutely sure that you didn't have a startPrank somewhere in your code base?

Cc @mds1.

Oh, could be a plain vm.prank actually, going to double check

[grandizzy]

changePrank with no prank started used to work

This should never have been the case. See #4779. Are you absolutely sure that you didn't have a startPrank somewhere in your code base?
Cc @mds1.

Oh, could be a plain vm.prank actually, going to double check

@PaulRBerg yeah, you're right, I updated test contract sample in PR description, thanks for flagging

[mds1]

I think we should keep the behavior from #4827, as if you have a stopPrank without a startPrank semantically that doesn't make sense and maybe you have a bug. Then we'd implement #4826 (comment), which removes the need for changePrank and would fix the UX

[grandizzy]

I think we should keep the behavior from #4827, as if you have a stopPrank without a startPrank semantically that doesn't make sense and maybe you have a bug. Then we'd implement #4826 (comment), which removes the need for changePrank and would fix the UX

Thank you, I think this makes sense. Do you have any timeline for #4826 , not sure if I should start fixing tests (pretty substantial :) ) at this point and then update them again when #4826 gets in. Or if I should just lock version that works here atm and update test only once when #4826 ready.

[mds1]

@4meta5 is working on that PR so deferring to them on timeline :)

[Evalir]

@mds1 is this closeable?

[mds1]

I think so, if anyone disagrees just let me know why and we can reopen