Add logic to generate simulation report#4537
Conversation
|
Claude finished @MartinquaXD's task in 3m 23s —— View job PR Review: Add logic to generate simulation report
Nice, focused addition — the checkpoint-based approach over the call tracer reads clearly and the doc comments explaining the design choices (sig-check-via-vault-relayer, high-level-only traversal) are helpful. I found one correctness issue which I left as an inline comment:
Everything else looks good. The |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new report module to generate high-level simulation reports from Geth call traces, along with corresponding tests. The review feedback highlights a potential issue where Event::SignatureCheck could be pushed multiple times during multi-order settlements because the vault relayer is called once per trade, and suggests guarding the push to ensure it is only added once.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| } | ||
| } | ||
|
|
||
| fn process_frame(frame: &CallFrame, ctx: &Context, events: &mut Vec<Event>) { |
| || FlashLoanRouter::flashLoanAndSettleCall::abi_decode(&frame.input).is_ok() | ||
| { | ||
| events.push(Event::WrapperEntered { wrapper: to }); | ||
| for sub in &frame.calls { |
There was a problem hiding this comment.
is sub: subcalls?
a more explicit name would be better
| revert: frame.revert_reason.clone(), | ||
| }); | ||
| } else { | ||
| for sub in &frame.calls { |
| }); | ||
| } else { | ||
| for sub in &frame.calls { | ||
| process_frame(sub, ctx, events); |
There was a problem hiding this comment.
i know there's a limit to how large a frame can be, but the technically unbounded recursion here is a risk
2 participants
Description
The new simulation approach for the order verification has a few limitations and we'd like to know whether an order doesn't pass the simulation because the order is just broken or because of an edge case in our simulation.
Changes
This PR introduces new logic to basically turn a
CallFrametrace into a simple easy to digest simulation report. The report only concerns itself with specific checkpoints we need to hit throughout the settlement as those should be enough to give the caller a tip where to start debugging their order (hooks, signature, wrapper setup, etc.).We are relying on a callframe tracer instead of the more detailed structopt tracer because it is significantly faster, requires less memory and still gives us enough information to infer everything we need to know in our report.
How to test
Since this code will only run in shadow mode (in a follow up PR) I only sanity checked the report for a few specific transactions.