fix: update platform for DIP-18 HRP and improve SPV sync progress

[lklimek]

Summary

• Updates dashpay/platform to d6f4eb9 which fixes DIP-18 HRP from evo/tevo to dash/tdash
• Replaces the intermediate SyncProgress/DetailedSyncProgress/SyncStage translation layer with direct use of the upstream dash_spv::sync::SyncProgress API, eliminating ~120 lines of bridge code
• Fixes SPV sync progress accuracy and robustness:
  • Restores download-window optimization for headers so checkpoint-resumed syncs start near 0%
  • Replaces _ => 0.0 catch-all arms with explicit SyncState variants
  • Fixes filters progress using current_height() instead of downloaded() (session count vs absolute height)
  • Restores peer count and transitional stage labels in status text
  • Logs SPV headers errors before discarding them in transaction building
• Fixes blocks progress bar jumping backward by switching from processed/requested session counters to monotonically increasing last_processed block height relative to target_height
• Blocks progress bar now shows current / target heights instead of percentage

Test plan

• cargo clippy --all-features --all-targets -- -D warnings passes clean
• cargo +nightly fmt --all applied
• cargo test --all-features --workspace — all 263 tests pass
• Manual verification of SPV sync progress UI on testnet

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • More reliable SPV sync height retrieval to prevent "sync height unknown" errors when building transactions.

• New Features

  • Unified SPV progress reporting with per-component progress (headers, filter headers, masternodes, filters, blocks) and consolidated status text including peer count.

• Chores

  • Updated Dash-related dependencies to a newer development branch while preserving existing features.
  • Simplified internal SPV progress model and removed legacy detailed-progress paths.

• Style

  • Refined SPV progress UI: clearer component-level progress, checkpoint-style targets, and clearer progress text.

[coderabbitai]

📝 Walkthrough

Walkthrough

Consolidates SPV progress into a single SpvSyncProgress, removes DetailedSyncProgress, updates SpvManager, backend height access, and NetworkChooserScreen rendering to use the new progress API. Cargo.toml gains git patch overrides pointing dashcore-related crates at v0.42-dev. No public APIs were removed.

Changes

Cohort / File(s)	Summary
Dependency Updates Cargo.toml	Bumped dash-sdk revision and added a [patch."https://github.com/dashpay/rust-dashcore"] section overriding multiple dashcore-related crates to the v0.42-dev branch.
SPV Manager & Types src/spv/manager.rs	Removed DetailedSyncProgress and consolidated progress to SpvSyncProgress. Updated SpvStatusSnapshot and SpvManager fields/types, removed detailed progress state and helpers, changed watcher signature to watch::Receiver<SpvSyncProgress>, and removed determine_sync_stage.
Backend SPV access src/backend_task/core/mod.rs	Adjusted SPV height retrieval to call headers() then current_height(), adding an extra optional-handling layer and logging when headers are unavailable.
UI Progress Rendering src/ui/network_chooser_screen.rs	Reworked SPV UI to use SpvSyncProgress/SyncState. Added per-component start/target state, rebuild_spv_progress_state, per-component progress calculators, replaced detailed-progress branches with format_sync_progress, and synced network-change handling. Many render and state fields updated.
Miscellaneous ...	Small related adjustments across code to compile with the new progress model and updated types; no public API removals beyond detailed progress fields.

Sequence Diagram(s)

sequenceDiagram
  participant UI as "NetworkChooserScreen"
  participant Manager as "SpvManager"
  participant SPV as "dash-spv (sync)"
  participant Backend as "BackendTask/Core"

  UI->>Manager: status() / read_sync_progress()
  Manager-->>UI: SpvStatusSnapshot { sync_progress: Option<SpvSyncProgress> }
  SPV-->>Manager: watch -> SpvSyncProgress updates
  Manager->>Manager: spawn_progress_watcher -> update sync_progress_state
  UI->>Backend: request tx build (needs SPV height)
  Backend->>Manager: headers().ok().map(current_height())
  Manager-->>Backend: current height or None
  UI->>UI: format_sync_progress(progress, connected_peers)

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

🐰 I nibble code in moonlit rows,
One sync to watch, one stream that flows.
Headers, filters, blocks in line,
Watchers hum and UIs shine.
A carrot patch—clean, concise, and fine!

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 54.17% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix: update platform for DIP-18 HRP and improve SPV sync progress' accurately reflects the main changes: updating platform for DIP-18 HRP changes and refactoring SPV sync progress handling throughout the codebase.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into v1.0-dev

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/update-platform-dip18-hrp

---

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.}

[lklimek]

Closes #569

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@src/ui/network_chooser_screen.rs`:
- Around line 56-59: The per-screen progress fields headers_stage_start,
filter_headers_stage_start, blocks_stage_start, and blocks_target_height are not
reset when the active network changes, causing stale progress to persist; update
refresh_on_arrival() (or the code path that detects a current_network change) to
clear or reinitialize these fields (set the Option<u32> fields to None and
blocks_target_height to 0 or an appropriate initial value) whenever
current_network differs from the stored network for this screen (or
unconditionally on arrival) so the progress bars are recalculated from the new
network state; locate and update the NetworkChooserScreen struct fields
(headers_stage_start, filter_headers_stage_start, blocks_stage_start,
blocks_target_height) and the refresh_on_arrival() method to perform this reset.

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/ui/network_chooser_screen.rs (1)

1947-1974: ⚠️ Potential issue | 🟡 Minor

refresh_on_arrival relies on render-time network detection — works but has an edge case.

The previous review asked for resetting SPV progress fields here. The current approach detects network changes at render time via spv_progress_network (line 1347), which handles the primary concern. However, if SPV data is cleared and restarted on the same network without navigating away, the stale *_stage_start values persist because spv_progress_network still matches. This would cause the progress bar to stay at 0% until current_height surpasses the stale start, then jump.

This is a very narrow edge case (same-network clear + restart while viewing the screen) and self-corrects as sync progresses, so it's low priority.

🧹 Nitpick comments (2)

src/spv/manager.rs (1)

332-374: status() and status_async() are now functionally identical.

With detailed_progress_state removed, both methods perform the same lock reads. The only difference is the method signature (async vs sync). If the async variant isn't needed for an .await call site, consider removing the duplication. That said, keeping both is harmless if there's a plan to re-introduce async-only work later.

src/ui/network_chooser_screen.rs (1)

1345-1421: Windowed progress tracking logic is well-structured.

The download-window pattern (tracking stage start per component) is applied consistently across headers, filter headers, and filters. The blocks_stage_start is intentionally not cleared on transient non-Syncing states (e.g., WaitForEvents), which prevents the bar from jumping backward between batches — good design.

One observation: the progress-window tracking for headers, filter_headers, and filters follows an identical pattern (lines 1354–1405). This is a natural candidate for a small helper like update_window_start(&mut Option<u32>, state, current, target), but it's fine as-is given the clarity of the inline code.