fix: Let the examples start the network monitoring#194
Conversation
WalkthroughThree example files were updated to add graceful shutdown handling. Each example now imports Changes
Sequence DiagramsequenceDiagram
participant User
participant Main as Main Flow
participant Monitor as client.monitor_network()
participant Signal as Signal Handler
Main->>Main: sync_to_tip()
Main->>Main: Display stats
rect rgba(100, 200, 150, 0.2)
Note over Main,Signal: tokio::select! - Race two futures
Main->>Monitor: Start monitoring (non-blocking)
Main->>Signal: Start listening for CTRL+C
alt Network monitoring completes first
Monitor->>Main: Return result
Main->>Main: Print monitor result
else User presses CTRL+C
User->>Signal: CTRL+C signal
Signal->>Main: Signal received
Main->>Main: Print cancellation message
end
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
dash-spv/examples/filter_sync.rs (1)
48-65: Move stats printing before network monitoring for better UX.The stats are printed after the tokio::select! block completes (lines 57-65), meaning users won't see sync completion status until they press Ctrl-C or monitor_network encounters an error. This creates a confusing experience where the program appears to hang after "Watching address..." with no indication that sync completed successfully.
This is inconsistent with simple_sync.rs (which prints stats at lines 47-50 before monitoring) and spv_with_wallet.rs (which prints completion status before monitoring).
Apply this diff to improve user experience:
// Full sync including filters let progress = client.sync_to_tip().await?; + println!("Synchronization completed!"); + println!("Headers synced: {}", progress.header_height); + println!("Filter headers synced: {}", progress.filter_header_height); + + // Get statistics + let stats = client.stats().await?; + println!("Filter headers downloaded: {}", stats.filter_headers_downloaded); + println!("Filters downloaded: {}", stats.filters_downloaded); + println!("Filter matches found: {}", stats.filters_matched); + println!("Blocks requested: {}", stats.blocks_requested); + + println!("\nStarting network monitoring... (press Ctrl-C to stop)"); tokio::select! { result = client.monitor_network() => { println!("monitor_network result {:?}", result); }, _ = signal::ctrl_c() => { println!("monitor_network canceled"); } } - println!("Headers synced: {}", progress.header_height); - println!("Filter headers synced: {}", progress.filter_header_height); - - // Get statistics - let stats = client.stats().await?; - println!("Filter headers downloaded: {}", stats.filter_headers_downloaded); - println!("Filters downloaded: {}", stats.filters_downloaded); - println!("Filter matches found: {}", stats.filters_matched); - println!("Blocks requested: {}", stats.blocks_requested); - // Stop the client
🧹 Nitpick comments (2)
dash-spv/examples/simple_sync.rs (1)
51-58: LGTM: Network monitoring with graceful shutdown.The tokio::select! block correctly implements concurrent monitoring and signal handling. The placement after printing stats provides good user experience—users see sync results immediately, then monitoring begins.
Consider adding a message before the select block to clarify that monitoring has started:
println!("Starting network monitoring... (press Ctrl-C to stop)"); tokio::select! { result = client.monitor_network() => { println!("monitor_network result {:?}", result); }, _ = signal::ctrl_c() => { println!("monitor_network canceled"); } }dash-spv/examples/spv_with_wallet.rs (1)
51-58: LGTM: Network monitoring with graceful shutdown.The tokio::select! block correctly implements concurrent monitoring and signal handling. The placement after printing sync completion (line 44) provides good user experience.
Consider adding a message before the select block to clarify that monitoring has started:
println!("\nStarting network monitoring... (press Ctrl-C to stop)"); tokio::select! { result = client.monitor_network() => { println!("monitor_network result {:?}", result); }, _ = signal::ctrl_c() => { println!("monitor_network canceled"); } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
dash-spv/examples/filter_sync.rs(2 hunks)dash-spv/examples/simple_sync.rs(2 hunks)dash-spv/examples/spv_with_wallet.rs(2 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-08-21T05:01:58.949Z
Learnt from: QuantumExplorer
Repo: dashpay/rust-dashcore PR: 108
File: key-wallet-ffi/src/wallet_manager.rs:270-318
Timestamp: 2025-08-21T05:01:58.949Z
Learning: In the key-wallet-ffi design, wallets retrieved from the wallet manager via lookup functions should return const pointers (*const FFIWallet) to enforce read-only access and prevent unintended modifications. The wallet manager should control wallet lifecycle and mutations through specific APIs rather than allowing external mutation of retrieved wallet references.
Applied to files:
dash-spv/examples/simple_sync.rsdash-spv/examples/filter_sync.rsdash-spv/examples/spv_with_wallet.rs
📚 Learning: 2025-06-26T16:01:37.609Z
Learnt from: DCG-Claude
Repo: dashpay/rust-dashcore PR: 0
File: :0-0
Timestamp: 2025-06-26T16:01:37.609Z
Learning: The mempool tracking infrastructure (UnconfirmedTransaction, MempoolState, configuration, and mempool_filter.rs) is fully implemented and integrated in the Dash SPV client as of this PR, including client logic, FFI APIs, and tests.
Applied to files:
dash-spv/examples/filter_sync.rsdash-spv/examples/spv_with_wallet.rs
🧬 Code graph analysis (3)
dash-spv/examples/simple_sync.rs (1)
dash-spv/src/client/sync_coordinator.rs (1)
monitor_network(69-574)
dash-spv/examples/filter_sync.rs (1)
dash-spv/src/client/sync_coordinator.rs (1)
monitor_network(69-574)
dash-spv/examples/spv_with_wallet.rs (1)
dash-spv/src/client/sync_coordinator.rs (1)
monitor_network(69-574)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (19)
- GitHub Check: RPC Tests (stable, true)
- GitHub Check: Strict Warnings and Clippy Checks
- GitHub Check: SPV Components Tests
- GitHub Check: Core Components Tests
- GitHub Check: fuzz (dash_script_bytes_to_asm_fmt)
- GitHub Check: fuzz (hashes_sha512)
- GitHub Check: fuzz (hashes_json)
- GitHub Check: fuzz (dash_deserialize_script)
- GitHub Check: fuzz (dash_outpoint_string)
- GitHub Check: fuzz (dash_deserialize_address)
- GitHub Check: fuzz (hashes_ripemd160)
- GitHub Check: fuzz (hashes_sha1)
- GitHub Check: fuzz (hashes_cbor)
- GitHub Check: fuzz (hashes_sha512_256)
- GitHub Check: fuzz (hashes_sha256)
- GitHub Check: fuzz (dash_deser_net_msg)
- GitHub Check: fuzz (dash_deserialize_witness)
- GitHub Check: fuzz (dash_deserialize_block)
- GitHub Check: fuzz (dash_deserialize_amount)
🔇 Additional comments (3)
dash-spv/examples/simple_sync.rs (1)
10-10: LGTM: Signal handling import.The tokio::signal import is correctly added to support graceful shutdown via Ctrl-C.
dash-spv/examples/filter_sync.rs (1)
11-11: LGTM: Signal handling import.The tokio::signal import is correctly added to support graceful shutdown via Ctrl-C.
dash-spv/examples/spv_with_wallet.rs (1)
11-11: LGTM: Signal handling import.The tokio::signal import is correctly added to support graceful shutdown via Ctrl-C.
The examples currently don't start
PeerNetworkManager::monitor_networkso there is no communication happening.Summary by CodeRabbit