feat(dashpay): live vote details in the contested request sheet - #958
Conversation
The request sheet only said "you already requested this name" — no tallies, no deadline, no join window. It now shows a "Network vote so far" card whenever an active contest exists on the label (yours or anyone's): every contender with their masternode vote tally (own identity labeled "You", sorted by votes), Abstain and Lock counts, the voting deadline with time (testnet polls are minutes long), and until when new contenders can still join — derived from the end time per rs-platform-version's allow_other_contenders_time (mainnet: 1 week of the 2-week poll; testing envs: 45 min of 90). "Joining closed" once the window passed. Nothing renders while the state is unavailable — no fabricated zero-tallies. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 29 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Comment |
* fix(dashpay): remove duplicated contenderJoinDeadline after parallel merges develop stopped compiling: #958's branch and #965 each carried the identical contenderJoinDeadline(voteEnd:) helper, and their squash merges landed both copies in UsernameMarketplaceService ("invalid redeclaration"). Keep one. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ui): a Core self-send shows the amount it moved, not the net-change 0 A 1.2 DASH internal transfer between the wallet's own transparent addresses rendered "0 Đ": the net-change model deliberately derives 0 for a move (every input and output is owned), and unlike the to-Shielded / to-Platform / identity asset locks there was no recorded amount to override it. Promote the Watch payload's reconstruction to the phone display, fee-EXCLUSIVE to match .sent rows: the owned-output total IS the moved amount of a self-send; owned inputs minus fee are the fallback while the TXO join hasn't reconciled. CoinJoin mixing rows keep their deliberate net semantics, and an unreconstructable amount stays 0 rather than guessing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ui): reconstruct only asset-lock moved amounts; self-sends keep net 0 QA falsified the owned-output reconstruction immediately: the "1.2 self-send" was actually an untracked asset lock, and owned outputs are its ~825 change, not the moved amount (credit outputs live in the lock payload, not in wallet TXOs). For an asset lock the locked amount IS derivable: owned inputs − owned outputs − fee. Plain .moved self-sends go back to the honest net-change 0 — destination-vs-change is not derivable from owned totals. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
1 participant
Issue being fixed or feature implemented
Testnet QA follow-up to #955: the contested request sheet only said "you already requested this name" — no tallies, no deadline, no join window. (This commit was originally pushed to #955's branch minutes after that PR merged, so it never landed; re-based here onto current develop.)
What was done
A "Network vote so far" card in
RegisterNameSheet, shown whenever an active contest exists on the label — both for a request of your own and for a contest you'd join as a contender:allow_other_contenders_time: mainnet joins are open the first week of the two-week poll, testing environments the first 45 minutes of the 90-minute poll (UsernameMarketplaceService.contenderJoinDeadline, constants documented against their source).Data comes from the existing
fetchContestVoteState(ContestVoteState: contender tallies, abstain/lock votes, end time, winner). The card renders nothing while vote state is unavailable or Platform hasn't indexed the contest — never fabricated zero-tallies.How Has This Been Tested?
Clean
dashpayarm64 simulator build on top of current develop. Installed on the testnet QA simulator carrying a live in-flight contest ("greg"); sheet verification ongoing in the same QA session. (Unit-test target pre-existing broken.)Breaking Changes
None.
Checklist:
For repository code-owners and collaborators only
🤖 Generated with Claude Code