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: e9cf989b-ec58-45b1-a4e2-42f50bb7b649

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

📝 Coding Plan

• Generate coding plan for human review comments

---

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: TUI Dashboard Implementation

I've completed a comprehensive review of the TUI dashboard implementation. Here's my detailed analysis:

✅ Overall Assessment

This is a well-architected TUI implementation that cleanly separates concerns and integrates nicely with the existing ev-dev tool. The code quality is generally high with good use of async/await patterns and proper terminal handling.

🎯 Strengths

1. Clean Architecture: Well-separated modules (app, ui, events, tracing_layer) with clear responsibilities
2. Proper Terminal Handling: Robust cleanup with TerminalGuard and panic hook to restore terminal state (/home/runner/work/ev-reth/ev-reth/bin/ev-dev/src/tui/mod.rs:21-34)
3. Real-time Updates: Efficient async channel-based communication for logs and balance updates
4. Memory Management: Proper bounds on log/block storage (MAX_LOGS: 1000, MAX_BLOCKS: 200) in /home/runner/work/ev-reth/ev-reth/bin/ev-dev/src/tui/app.rs:6-7
5. User Experience: Intuitive keyboard navigation and visual feedback

🚨 Critical Issues

1. Unbounded Balance Poller (/home/runner/work/ev-reth/ev-reth/bin/ev-dev/src/tui/app.rs:199-224)

let provider = match ProviderBuilder::new()
    .connect_http(rpc_url.parse().expect("valid RPC URL"))
{
    provider => provider, // Creates new connection every 2 seconds!
};

Issue: Creates a new HTTP provider connection every 2 seconds, which will leak connections and eventually exhaust system resources.

Fix: Move provider creation outside the loop and handle connection failures gracefully.

2. Silent Error Handling (/home/runner/work/ev-reth/ev-reth/bin/ev-dev/src/tui/tracing_layer.rs:81)

let _ = self.tx.try_send(entry); // Silently drops logs on backpressure

Issue: If the UI can't keep up with log volume, entries are silently dropped without any indication.

Fix: Consider logging dropped entries or implementing backpressure handling.

⚠️ Moderate Issues

3. Race Condition Risk (/home/runner/work/ev-reth/ev-reth/bin/ev-dev/src/main.rs:322-328)

The tracing subscriber is initialized before the node starts, which could miss early log messages or cause issues if multiple subscribers try to initialize.

4. Integer Overflow Risk (/home/runner/work/ev-reth/ev-reth/bin/ev-dev/src/tui/app.rs:172-187)

let frac_val: u64 = frac.try_into().unwrap_or(0); // Could panic on conversion

While using unwrap_or(0), the try_into() handles the case, but the arithmetic operations could theoretically overflow with malicious input.

5. Potential Panic in Hash Formatting (/home/runner/work/ev-reth/ev-reth/bin/ev-dev/src/tui/app.rs:127-131)

format!("{}..{}", &h[..6], &h[h.len() - 4..]) // Assumes hash length > 10

Could panic if hash is shorter than expected due to string slicing.

🔍 Minor Issues & Suggestions

6. Error Propagation (/home/runner/work/ev-reth/ev-reth/bin/ev-dev/src/tui/app.rs:214-217)

Err(_) => balances.push("? ETH".to_string()), // All errors treated the same

Different error types (network, parsing, etc.) could provide more specific user feedback.

7. Code Organization

• Consider extracting magic numbers (100ms tick interval, 2s balance poll) into constants
• The parse_block_from_fields method could be more robust with proper error handling

8. Performance Considerations

• The 100ms UI refresh rate is reasonable but could be configurable
• Balance polling every 2 seconds is appropriate for dev purposes
• Consider debouncing rapid log updates during high activity periods

🔒 Security Assessment

✅ No significant security concerns identified:

• No direct file system access or user input handling
• Proper bounds checking on collections
• Read-only operations for most functionality
• RPC calls are to localhost development endpoints

🧪 Test Coverage

❌ Critical Gap: No tests found for the TUI implementation. Recommendations:

1. Unit Tests Needed:

   • format_ether() function with edge cases
   • parse_block_from_fields() with malformed input
   • Key event handling logic

2. Integration Tests:

   • Terminal cleanup on various exit conditions
   • Channel communication under load
   • Provider connection handling

3. Manual Testing Scenarios:

   • Terminal resize during operation
   • Network connectivity issues
   • High log volume scenarios

📋 Recommendations

Priority 1 (Fix Immediately):

1. Fix the connection leak in balance poller
2. Add proper error handling for hash formatting
3. Add basic unit tests for critical functions

Priority 2 (Next Release):

1. Implement proper backpressure handling for logs
2. Add configuration for polling intervals
3. Improve error reporting for balance updates

Priority 3 (Future Enhancement):

1. Add filtering capabilities for logs
2. Implement log export functionality
3. Add configurable refresh rates

📊 Code Quality Score: 7.5/10

• ✅ Architecture: Excellent (9/10)
• ✅ Readability: Good (8/10)
• ⚠️ Error Handling: Fair (6/10)
• ❌ Test Coverage: Poor (3/10)
• ✅ Performance: Good (8/10)
• ✅ Security: Excellent (9/10)

---

Verdict: This is a solid TUI implementation with good architecture but needs immediate attention to the connection leak issue and test coverage. The core functionality is well-designed and the user experience is intuitive.

---