Summary

• Fixed bug where all calls in a sequence displayed identical block numbers and timestamps, making test case reproduction impossible
• Added immutable BlockNumber and BlockTimestamp snapshots to CallSequenceElementChainReference to preserve execution context
• Fixed pre-existing nil pointer issues in String() method for simple transfers without contracts

Context

The fuzzer intentionally modifies pending block headers in-place during execution (mimicking cheat codes like vm.warp/vm.roll). This allows time to advance within a single block for efficiency and test flexibility. However, all CallSequenceElement objects shared a pointer to the same mutable block header, causing the display to show the FINAL values for all calls instead of their actual execution context.

This fix captures immutable snapshots when each call executes, preserving the actual block number and timestamp without changing execution semantics.

Test plan

• Run new unit tests: go test -v ./fuzzing/calls/...
  • TestCallSequenceBlockTimestampDisplay - verifies distinct values for calls with delays
  • TestCallSequenceDisplayWithoutChainReference - verifies graceful nil handling
  • TestCallSequenceMultipleCallsSameBlock - verifies same values for zero-delay calls
• Run full test suite to verify no regressions: go test -v ./...
• Manual testing: Run fuzzer with blockNumberDelayMax/blockTimestampDelayMax configured, trigger a test failure, verify printed sequence shows distinct block/time values
• Corpus replay: Verify existing corpus files still replay correctly with updated display logic

🤖 Generated with Claude Code