feat(ev-dev): part 5 – add interactive TUI dashboard

[randygrok]

Description

Adds an interactive terminal UI dashboard to ev-dev with the --tui flag. The TUI displays real-time blocks, logs, and accounts panels using ratatui, with a custom tracing layer that captures log events in real-time. Plain log output remains the default behavior.

Type of Change

• New feature (non-breaking change which adds functionality)

Testing

• TUI renders blocks, logs, and accounts panels
• Keyboard navigation works (Tab, arrows, q to quit)
• Terminal properly restored on exit or panic
• Plain log output mode (--tui off) unchanged

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 333b21fb-390d-40bf-b21e-ff265f9159b4

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/ev-dev-part5-tui

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Claude finished @randygrok's task —— View job

---

Code Review Complete

I've thoroughly reviewed the TUI dashboard implementation. This is a well-structured addition with good architecture, but there are several important issues to address:

Critical Issues 🚨

1. Terminal Restoration on Panic (tui/mod.rs:29-34)

• The panic hook sets up terminal restoration, but there's a race condition
• If another panic occurs during restoration, it could leave the terminal in a broken state
• Recommendation: Add panic guard to prevent recursive panic handling

2. Channel Unbounded Growth (tui/app.rs:97-113, main.rs:317)

• Log channel has 10,000 capacity but no backpressure handling
• If TUI can't keep up with log volume, memory will grow unbounded
• Recommendation: Use try_send() with proper error handling or implement log level filtering

3. Balance Polling Error Handling (tui/app.rs:211-214)

• Network errors are silently converted to "? ETH" without any indication of the problem
• No retry logic or connection health indicators
• Recommendation: Implement exponential backoff and surface connection status in UI

Performance Concerns ⚡

1. Frequent RPC Calls (tui/app.rs:202)

• Balance polling every 2 seconds for all accounts
• Could overwhelm local RPC or cause UI stuttering with many accounts
• Recommendation: Make polling interval configurable or use batch requests

2. String Allocations in Hot Path (tui/ui.rs:228-259)

• Heavy string formatting in the log rendering loop
• rsplit() and multiple Span allocations on every frame
• Recommendation: Cache formatted strings or use string interning

3. VecDeque Operations (tui/app.rs:102-104)

• push_front() on blocks is O(n) operation
• Could cause frame drops with high block frequency
• Recommendation: Use ring buffer or reverse iteration order

Code Quality Issues 📋

1. Magic Numbers (tui/app.rs:6-7)

const MAX_LOGS: usize = 1000;
const MAX_BLOCKS: usize = 200;

• Hard-coded limits without configuration options
• Recommendation: Make configurable via CLI args or config file

2. String Parsing Without Validation (tui/app.rs:124-134)

"block_number" => number = v.parse().ok(),
"tx_count" => tx_count = v.parse().unwrap_or(0),

• Mixed error handling - some use .ok(), others unwrap_or()
• Recommendation: Consistent error handling strategy

3. Potential Integer Overflow (tui/app.rs:172-187)

let ether_unit = U256::from(10u64).pow(U256::from(18));

• Format calculation could overflow for extremely large values
• Recommendation: Add bounds checking

Security Considerations 🔒

1. Resource Exhaustion

• No rate limiting on log ingestion
• Malicious or buggy components could flood logs and consume memory
• Recommendation: Implement rate limiting and log level filtering

2. Terminal State Management

• Terminal mode changes affect entire process
• No validation that terminal supports required features
• Recommendation: Add terminal capability detection

Positive Aspects ✅

1. Excellent Architecture: Clean separation of concerns across modules
2. Resource Management: Good use of RAII with TerminalGuard
3. Error Recovery: Proper panic hook for terminal restoration
4. UI Design: Well-organized layout with clear information hierarchy
5. Code Organization: Logical module structure and clear naming

Test Coverage 🧪

Currently no tests are present for the TUI functionality. Consider adding:

• Unit tests for format_ether() function
• Mock tests for balance polling logic
• Integration tests for terminal state management
• Property tests for log parsing edge cases

Recommendations Summary

1. High Priority: Fix terminal restoration race condition and channel backpressure
2. Medium Priority: Optimize string allocations and VecDeque operations
3. Low Priority: Add configuration options and improve error messages

Overall, this is a solid implementation that adds significant value to the developer experience. The identified issues are mostly around edge cases and performance optimization rather than fundamental architectural problems.

---