fix(dash-spv-bench): count distinct transactions, not processing passes - #984
Draft
ZocoLini wants to merge 1 commit into
Draft
fix(dash-spv-bench): count distinct transactions, not processing passes#984ZocoLini wants to merge 1 commit into
ZocoLini wants to merge 1 commit into
Conversation
Contributor
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueThanks 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 |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## dev #984 +/- ##
==========================================
+ Coverage 77.14% 77.16% +0.02%
==========================================
Files 329 329
Lines 82998 83053 +55
==========================================
+ Hits 64026 64087 +61
+ Misses 18972 18966 -6
|
ZocoLini
force-pushed
the
fix/bench-distinct-tx-count
branch
2 times, most recently
from
August 26, 2026 12:32
aa75024 to
a3d6645
Compare
`BlocksProgress::transactions` was a running sum, incremented per block application by however many txids the wallet reported as new to it. A block reaches the wallet more than once during a sync, and a record the wallet dropped at finalization is reported new again on the next pass, so the number measured how much re-scanning a run happened to do rather than what it found, and varied run-to-run on an identical wallet and chain. The dashboard and the bench report both showed it. The wallet already knows the answer, so it is asked instead of tracked: `WalletInterface::tx_count` unions the txids its wallets know, and the blocks manager sets the progress value from it once per drain rather than accumulating. Nothing downstream changes shape — the field stays a `u32`, so `BlocksProgress` is still cheap to clone on every progress read. Unioned rather than summed, at both levels: one transaction can touch several accounts, and be relevant to several wallets. The report's per-wallet line had the same problem from the other side. It showed `retained_records`, which counts live records only — and with `keep-finalized-transactions` off a chainlocked record is pruned to its txid, so a fully synced wallet reported near zero. It now shows `txids`, from `WalletInfoInterface::txids` over a `ManagedAccountTrait::collect_txids` primitive that reads both halves. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015NhHBDGiKfiGpy7FwooyfS
ZocoLini
force-pushed
the
fix/bench-distinct-tx-count
branch
from
August 26, 2026 14:25
a3d6645 to
34aec53
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The dashboard's transaction figure and the report's
transactions:line were both additive counters incremented per block application. A block reaches the wallet more than once during a sync, so the number measured how much re-scanning a run happened to do rather than what it found, and varied run-to-run on an identical wallet and chain.Both now count distinct txids collected from
BlockProcessed.The report's per-wallet line also gains
known_txids.retained_recordscounts live records only, and withkeep-finalized-transactionsoff a chainlocked record is pruned to its txid — so a fully synced wallet reported zero.ManagedAccountTrait::collect_known_txidsreturns both halves.