feat(debugger): improve debugger experience when tests fail due to event mismatch

[smol-ninja]

Component

Forge, Foundryup

Describe the feature you would like

Problem

When a test fails due to event mismatch, Foundry logs FAIL: log != expected log; counterexample calldata=0x1234....1234 without specifying which event parameter did not match.

Though this is fine for simple tests, in case of fuzz testing, it becomes very problematic. This is because Foundry prints lengthy calldata forcing to scroll extensively to trace down the error.

👾 Link to warp block

Solution 1

Log the first mismatched event parameter in the failure message:

FAIL: log != expected log event_name:event_parameter expectedValue != actualValue; counterexample calldata=0x1234..1234

This would make it easier to identify which event parameter did not match with the expected value without having to scroll down so much.

Solution 2

Add a Foundry cheat code to enable/disable calldata logs. It can be called display_calldata

Most of the times, having calldata printed is of little value. This is because, use of bound can change the value of the input parameters. Thus, having a cheatcode to enable calldata logging can be more useful than having it enabled by default.

Additional context

No response

[grandizzy]

Hey @smol-ninja would approach in #8686 (issue #8506) work for your case? Thank you

[smol-ninja]

Hi @grandizzy, I looked at the links that you provided.

If an emitted event is marked as unmatched, it can then be highlighted as an error in red.

If it only highlights the unmatched event, it doesn't work for my case. I suppose calldata will still be emitted, so having this new style would be helpful but doesn't eliminate the need to scroll through all the calldata before seeing the unmatched event.

[grandizzy]

Got it, ok, maybe we can accommodate in same pr

[topocount]

@grandizzy I'd originally set out to implement @smol-ninja's first proposed solution but realized there wasn't an easy way to decode the event calldata back to english for the error string without accessing the tracing inspector, which is only available at higher verbosity. Looking at your latest response has helped me to realize my workaround isn't an easy way around this issue. Would it be permissible to have an opaque log != expected log: please rerun with -v for more details error without verbosity, and then provide the more detailed error when verbosity is set?

[smol-ninja]

@topocount, would -vvv provide detailed error, as I have requested? If yes, then it looks good to me.

[grandizzy]

yep, makes sense