figure out failing emits with latest foundry

[holic]

main branch's tests started failing. I think it might be this: foundry-rs/foundry#4920

The intended behavior is that it only works for the next immediate call. This new behavior only allows to:

• Call the cheatcode AND fill the expected emit right after calling the cheatcode. Declaring the cheatcode N times and then filling N events will fail.
• match events after the next CALL is triggered. Events not triggered by a call will be ignored. Events nested in the triggered CALL subtree will be matched. If the events defined are not matched, the execution will revert.

It's a little unclear by the above "nested in the CALL subtree" description if this should succeed or fail in our case, but I noticed that StoreCore.pushToField is doing more calls internally before emitting, so maybe it's not matching on the new criteria for expectEmit?

This feels like a bummer constraint if so, and wonder if there are ways around this or alternative vm helpers.

I asked about this in the Foundry Support Telegram group. If there's not a quick/clear way to test for emits in the same way with the latest foundry version, we may need to pin our version for now.

Another option is to use Vulcan test utils, which has some nicer ergonomics: https://github.com/nomoixyz/vulcan

mc.doSomethingElse();

// Check event emissions
expect(address(mc).lastCall()).toHaveEmitted(
    "SomeEvent(address,bytes32,uint256)",
    [address(1).topic(), any()], // Event topics
    abi.encode(123) // Event data
);

(I also have an open issue and they have a pending PR for better gas reporting)

[holic]

I tried out Vulcan but it had some internal reverts that I couldn't track down, so I gave up (flight is about to land).

I did, however, find a way around the foundry issue using vm.recordLogs() and vm.getRecordedLogs(), but I need to write a helper to clean it up. Will report back with some code later!

[alvrs]

Another simple work around for this is to call the functions on a wrapper contract instead of the library (see #815). I'm actually confused why only two of the store tests are failing after the foundry update and not all of them - in my mind none of them should match the criteria of "expect an event in the next CALL" because the event is emitted via a library and therefore not inside a CALL.

[holic]

Another simple work around for this is to call the functions on a wrapper contract instead of the library (see #815). I'm actually confused why only two of the store tests are failing after the foundry update and not all of them - in my mind none of them should match the criteria of "expect an event in the next CALL" because the event is emitted via a library and therefore not inside a CALL.

Weird! Is this something reproducible and worth bubbling up to Foundry team?

Glad it was a much easier fix than I was anticipating.