(feat): tracing support for state-sync transactions #2172
Claude / Claude Code Review
completed
Apr 3, 2026 in 37m 38s
Code review found 1 important issue
Found 4 candidates, confirmed 3. See review comments for details.
Details
| Severity | Count |
|---|---|
| 🔴 Important | 1 |
| 🟡 Nit | 1 |
| 🟣 Pre-existing | 0 |
| Severity | File:Line | Issue |
|---|---|---|
| 🔴 Important | consensus/bor/statefull/processor.go:197-226 |
callTracer fails for state-sync txs with multiple bridge events |
| 🟡 Nit | eth/tracers/api.go:169-175 |
TraceConfig.IOFlag and TraceConfig.Path are dead fields after IO tracing removal |
Annotations
Check failure on line 226 in consensus/bor/statefull/processor.go
claude / Claude Code Review
callTracer fails for state-sync txs with multiple bridge events
When a state-sync transaction contains 2 or more bridge events, tracing it with `callTracer` (or any stack-based tracer) returns a fatal error: "incorrect number of top-level calls". This is because `ApplyStateSyncEvents` calls `ApplyBorMessage` in a loop — each call fires independent `OnEnter(depth=0)`/`OnExit(depth=0)` hooks, causing the callTracer's internal stack to grow beyond 1 entry, which violates its one-top-level-call-per-tx invariant. The fix is to wrap all per-event EVM calls inside
Check warning on line 175 in eth/tracers/api.go
claude / Claude Code Review
TraceConfig.IOFlag and TraceConfig.Path are dead fields after IO tracing removal
TraceConfig.IOFlag (*bool) and TraceConfig.Path (*string) remain declared in the struct after this PR removes all IO tracing code, but neither field is read anywhere in the codebase. Clients passing {"IOFlag": true, "Path": "/some/dir"} will have those fields silently deserialized and ignored with no error or warning. The fix is to remove both fields or return an error if either is set.
Loading