feat: dispatch progress callback on registration

[xdustinface]

Send the current sync progress to a newly registered callback immediately on registration, so callers don't have to wait for the next progress update to get the current state.

Based on:

• chore: drop unused _TestCallbackData #472

Summary by CodeRabbit

• Bug Fixes

  • Progress callbacks now synchronously retrieve and immediately dispatch the current progress state when registered, ensuring callbacks are invoked with up-to-date status information upon registration.

• Tests

  • Added comprehensive test coverage for progress callback registration and initial state emission verification.

[coderabbitai]

📝 Walkthrough

Walkthrough

The progress callback mechanism in the FFI client is enhanced to synchronously dispatch the current progress state immediately when a callback is registered, instead of only storing the callback for future updates. A corresponding test validates this new behavior.

Changes

Cohort / File(s)	Summary
Progress Callback Enhancement dash-spv-ffi/src/client.rs	Modified dash_spv_ffi_client_set_progress_callback to retrieve and immediately dispatch current progress to the callback upon registration, rather than only storing the callback for future updates.
Progress Callback Tests dash-spv-ffi/tests/test_client.rs	Added FFI test scaffolding including ProgressCallbackData helper struct, test_progress_callback extern "C" function, and test_set_progress_callback_emits_progress test to verify callback behavior and initial progress state delivery.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 Hops with glee, a callback so neat!
When progress is set, dispatch is fleet—
No waiting around for future ticks,
Just grab the state and do the tricks! ✨

🚥 Pre-merge checks | ✅ 3

✅ 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 'feat: dispatch progress callback on registration' directly and clearly describes the main change: immediately dispatching progress to a newly registered callback.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

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

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/initial-progress

---

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

[github-actions]

This PR has merge conflicts with the base branch. Please rebase or merge the base branch into your branch to resolve them.

[coderabbitai]

🧹 Nitpick comments (1)

dash-spv-ffi/tests/test_client.rs (1)

91-98: Minor: assert! in extern "C" can be UB if called from actual C code.

Panicking across an FFI boundary is undefined behavior. Since this callback is only invoked from Rust test code (via cb.dispatch()), it's safe here. However, if this pattern were copied to production code or the callback were invoked from C, consider replacing with a null check that sets an error flag instead of panicking.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@dash-spv-ffi/tests/test_client.rs` around lines 91 - 98, The extern "C"
callback test_progress_callback currently uses assert!(!progress.is_null())
which can panic across an FFI boundary; change it to perform an explicit null
check instead of asserting: inside test_progress_callback, check if
progress.is_null(), and if so record an error/invalid-pointer state on the
ProgressCallbackData (e.g., set a dedicated error or invalid flag stored in
data) and return early; otherwise safely dereference progress (as with
FFISyncProgress) and continue updating data.state and data.is_synced. Ensure you
reference the test_progress_callback, FFISyncProgress, and ProgressCallbackData
symbols when making the change.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@dash-spv-ffi/tests/test_client.rs`:
- Around line 91-98: The extern "C" callback test_progress_callback currently
uses assert!(!progress.is_null()) which can panic across an FFI boundary; change
it to perform an explicit null check instead of asserting: inside
test_progress_callback, check if progress.is_null(), and if so record an
error/invalid-pointer state on the ProgressCallbackData (e.g., set a dedicated
error or invalid flag stored in data) and return early; otherwise safely
dereference progress (as with FFISyncProgress) and continue updating data.state
and data.is_synced. Ensure you reference the test_progress_callback,
FFISyncProgress, and ProgressCallbackData symbols when making the change.

---

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 77840c9 and 544f28d.

📒 Files selected for processing (2)

• dash-spv-ffi/src/client.rs
• dash-spv-ffi/tests/test_client.rs