Skip to content

feat(dpns): unify safe masternode voting operations - #901

Open
lklimek wants to merge 50 commits into
v1.0-devfrom
feat/dpns-voting-unified
Open

feat(dpns): unify safe masternode voting operations#901
lklimek wants to merge 50 commits into
v1.0-devfrom
feat/dpns-voting-unified

Conversation

@lklimek

@lklimek lklimek commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

Why this PR exists

  • Problem: A DPNS vote could be accepted by Platform while Dash Evo Tool appeared to do nothing because a post-broadcast wait error was treated like an ordinary failure and the voting UI discarded the operation state.
  • What breaks without it: An operator selects a vote, submits it, sees the form reset without a useful result, and may retry even though the vote is already visible on Platform Explorer.
  • UX iteration (2026-07-21): the first implementation solved the above with a dedicated three-step "Voting Center" wizard and a Nodes/Voting/Scheduled sub-nav on the Masternodes tab. A UX review found the wizard more confusing than the single-screen alternative it was compared against, so voting was moved back into the existing DPNS Active contests screen (see "What was done").

What was done

  • Voting lives on DPNS → Active contests, not a separate wizard. Contests render as cards grouped into Needs your vote / Voted / Not votable by your nodes, with real vote controls kept visually distinct from the read-only tally counts, a sticky "Votes ready to cast" tray, and a Review-and-cast step (defaults to all nodes / cast now, with per-node timing available for the less common case). Remaining vote changes are shown up front (Platform allows four per contest).
  • Masternode detail screen no longer casts votes inline — it exposes a single "DPNS Voting" button that opens Active contests. The Masternodes tab's Nodes/Voting/Scheduled sub-navigation and the standalone Voting Center wizard were removed; Scheduled votes stays a DPNS subscreen as before.
  • Preserved the operation model: target-level operation locking, bounded per-voter concurrency, durable network-scoped operation journals, startup recovery, and journal-authoritative scheduled execution all carry over unchanged and back the redesigned screen (SubmitDpnsVoteOperation, typed per-target status, "Check again" / "Review again", the "Do not submit it again" unconfirmed-result guidance).
  • Treats cause-less post-broadcast wait failures as unconfirmed outcomes and reconciles them without automatically rebroadcasting; keeps a mismatched or absent reconciliation result unconfirmed instead of inferring rejection; preserves the originating network and typed vote choice through asynchronous result routing.
  • New: fixed a second per-frame hot-path freeze. The operation-journal read path was already moved off the render hot path earlier in this PR; a separate freeze source remained — dpns_current_vote_state() was doing a live storage read for every node × contest on every egui frame. It now performs one batched read per node during construction/explicit refresh and serves rendering from an in-memory snapshot, with a regression test asserting 100 poll lookups cost exactly one storage read per node.
  • Added/kept requirements, UX, test-case, and development-plan documentation for the DPNS voting experience, updated to make the card-based Active-contests design authoritative (the wizard-era sections are marked superseded, not deleted, so the design history stays legible).
  • Bounds the operation journal's long-term growth: terminal operations are pruned, target-lock conflict checks use a persistent incrementally-maintained index instead of a full journal scan, in-memory diagnostics are capped with oldest-entry eviction, and retired legacy records no longer re-scan forever.
  • Direct vote-dispatch paths (single submit, scheduled cast) recover the same way the scheduled sweep already did if a terminal write fails after broadcast, instead of leaving the target stuck until restart; covered by a fault-injection test.
  • DAPI-address-exhaustion context is attached to per-vote diagnostics recorded in the operation journal, so an operator sees why votes stalled when the network's DAPI addresses are exhausted.
  • An operator with no voting-capable masternode loaded sees an explicit explanation on Active contests with a "Load a masternode" action, instead of a silently empty/unreachable state.
  • Vote-choice labels in Recent voting activity and Scheduled Votes resolve to the candidate's name rather than a truncated Base58 identifier.
  • A "Voted" card's "You voted: …" label and highlighted choice always reflect the actual proved on-chain vote (with a Mixed state when loaded nodes disagree) — including immediately after a vote change, not just on first vote or after the next background refresh.
  • Scheduled Votes is now genuinely journal-authoritative end to end. Rows, statuses, and available actions (Remove / Cast now) are derived from the operation journal, falling back to the legacy compatibility table only when no journal entry exists for that voter/contest pair — a journaled-but-unmirrored schedule is no longer invisible, and a terminal status is no longer misdisplayed as Pending. Removing a single schedule and "Clear All" both route through guarded journal cancellation instead of touching the legacy table directly, so a vote that has already started executing can no longer be hidden from the UI while it's still in flight; Clear All reports a per-target outcome with a summary banner instead of silently doing nothing.
  • Terminal-operation pruning (used by "Clear completed scheduled votes") now derives eligibility from durable state instead of an in-memory set, so an interrupted cleanup is retried correctly instead of permanently losing track of what's prunable, and it no longer treats unrelated immediate-vote history as automatically prunable.
  • A scheduled-vote sweep completing while Active contests is hidden (covered by another screen) now correctly refreshes it, instead of leaving stale, disabled voting controls in place until the next full refresh.
  • Renamed the contest-level is_open_for_voter check — which silently ignored the voter it was named after — to is_votable, and replaced its tautological tests with ones that actually exercise the state-based logic it performs.
  • A failed vote submission no longer leaves the Review-and-cast window frozen on "Submitting votes…" with both Submit and Cancel disabled and no close control; it now correctly falls back to its Failed state so the operator can retry or dismiss it, without disturbing a genuinely-different submission still in flight.

User story

Imagine you are a masternode operator managing several voting identities. You open DPNS → Active contests, see at a glance which contests still need your vote, pick your choices, review exactly what will change, and cast or schedule them — with a truthful final or unconfirmed result and no risk of an accidental duplicate broadcast.

Testing

  • cargo test --test kittest --all-features masternode_tab::20 passed (independently re-run against a pre-fix checkout to confirm RED, then against HEAD to confirm GREEN — not a tautological pass)
  • cargo test --lib --all-features ui::dpns::dpns_contested_names_screen::tests::9 passed, incl. the no-voting-key state, candidate-name resolution, and proved-vote-on-change regression tests
  • cargo test --lib --all-features ui::state::dpns_vote_state::tests::1 passed
  • cargo test many_poll_states_use_one_storage_read_per_node --all-features — freeze regression, passed
  • cargo test correlated_vote_result_routes_when_active_contests_is_hidden --all-features — passed
  • cargo test --all-features dpns_result_routing_tests5 passed (incl. sweep-completion and Clear-All hidden-route regressions)
  • cargo test --all-features dpns_vote_operations::tests::36 passed (guarded removal/Clear All, durable resumable pruning, immediate-history preservation)
  • cargo test --all-features identity_db::tests::33 passed
  • cargo test --all-features contested_name::13 passed
  • cargo test --all-features contested_names::26 passed
  • cargo test failed_submission_releases_the_review_window unrelated_error_keeps_the_pending_submission_in_progress --all-features2 passed (stuck Review-and-cast window regression)
  • cargo check --all-features --bin dash-evo-tool — clean
  • cargo clippy --bin dash-evo-tool --all-features -- -D warnings — clean
  • cargo fmt --all -- --check — clean
  • git diff --check — clean
  • Full cargo test --all-features --workspace and clippy sweep left to CI (this PR touches only Rust files already covered by tests.yml/clippy.yml's standard gate).

No funded live-network vote was broadcast during verification.

Breaking changes

None.

Checklist

Attribution

🤖 Co-authored by Claudius the Magnificent AI Agent

@coderabbitai

coderabbitai Bot commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review
📝 Walkthrough

Walkthrough

This change introduces a unified DPNS voting workflow with proved vote-state snapshots, durable target journals and locks, coordinated execution, reconciliation for ambiguous results, scheduled-vote migration, and a shared Masternodes Voting Center.

Changes

DPNS voting workflow

Layer / File(s) Summary
Requirements and workflow specification
docs/ai-design/2026-07-16-dpns-voting-experience/*, docs/user-stories.md
Defines unified quick, bulk, scheduled, recovery, persistence, accessibility, and testing requirements.
Vote state and operation contracts
src/model/dpns_voting.rs, src/context/dpns_vote_state.rs, src/context/dpns_vote_operations.rs, src/context/mod.rs
Adds typed targets, statuses, operation IDs, proved current-vote snapshots, durable journals, exact-target locks, migration, and bounded dispatch coordination.
Submission and recovery execution
src/backend_task/contested_names/*, src/backend_task/mod.rs, src/backend_task/error.rs
Replaces legacy vote tasks with journaled submission, per-voter serialization, typed outcomes, reconciliation, scheduled sweeps, and structured task correlation.
Shared operator workspace
src/ui/masternodes/*, src/ui/state/dpns_vote_*, src/ui/dpns/dpns_contested_names_screen.rs
Adds the Nodes/Voting/Scheduled Masternodes workflow, three-step composer, operation progress, scheduled management, and DPNS routing.
Feedback and validation
src/app.rs, tests/kittest/masternode_tab.rs, src/wallet_backend/kv_test_support.rs
Adds outcome banners, hidden-screen result forwarding, navigation regression tests, and deterministic KV write-failure support.

Estimated code review effort: 5 (Critical) | ~120 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title is concise and accurately captures the main change: unifying masternode voting operations under a safer DPNS flow.
✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feat/dpns-voting-unified

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

Comment @coderabbitai help to get the list of available commands.

@lklimek
lklimek marked this pull request as ready for review July 16, 2026 13:35
@thepastaclaw

thepastaclaw commented Jul 16, 2026

Copy link
Copy Markdown
Collaborator

⛔ Blockers found — Sonnet deferred (commit 513af26)
Canonical validated blockers: 3

@lklimek

lklimek commented Jul 16, 2026

Copy link
Copy Markdown
Contributor Author

Heads-up for whoever merges this: a PR-#860 review-feedback cleanup pass just landed a stopgap fix on docs/platform-wallet-migration-design for backend_task/contested_names/mod.rs's cast_due_scheduled_votes/CastScheduledVote — nested per-vote Platform rejections were being silently reported as a successful cast. That patch adds TaskError::ScheduledVoteSweepFailed/ScheduledVoteRejected/ScheduledVoteResultUnavailable/NoVotingIdentity and a BackendTaskSuccessResult::ScheduledVoteSweepCompleted result.

Since this PR replaces vote_on_dpns_name/VoteOnDPNSNames/ScheduleDPNSVotes wholesale with the DpnsVoteOperation journal model (execute_dpns_vote_operation/reconcile_dpns_vote_operation), it already fixes this same problem more thoroughly via per-target status tracking — expect a merge conflict in contested_names/mod.rs when this rebases past that commit. Resolve toward this PR's architecture there.

Two related pieces in the same stopgap commit are not superseded and should be preserved through the merge: a MigrationState::Ready addition (so scheduled-vote sweeps aren't permanently blocked post-migration) and a fix to app.rs's deferred-vote-sweep-cutoff handling that waits on ScheduledVoteSweepCompleted/ScheduledVoteSweepFailed before clearing the retry cutoff — that gating logic will need to be re-pointed at this PR's own completion signal instead.

🤖 Co-authored by Claudius the Magnificent AI Agent

@thepastaclaw thepastaclaw left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preliminary review — Codex only

The PR establishes a strong shared journal and voting workflow, and all 21 focused DPNS vote tests pass. Four in-scope defects remain: ambiguous post-broadcast errors can release duplicate-prevention locks, cancellation can overwrite active execution, scheduled edits are not crash-atomic, and legacy vote-state migration can cross network boundaries.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

  • Codex reviewers: gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
  • Verifier: gpt-5.6-sol — verifier
  • Sonnet: not run (deferred by blocker gate)

🔴 3 blocking | 🟡 1 suggestion(s)

🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/backend_task/contested_names/vote_on_dpns_name.rs`:
- [BLOCKING] src/backend_task/contested_names/vote_on_dpns_name.rs:120-136: Post-broadcast wait errors release the duplicate-prevention lock
  The SDK broadcasts at `vote.rs:114-117` and then enters a separate wait path. That wait can return transport, address-exhaustion, proof-verification, stale-metadata, context-provider, or invalid-response errors in addition to `StateTransitionBroadcastError`. This code treats every such variant as a pre-submission failure, so `classify_vote_attempt` records `FailedBeforeSubmission` and releases the target lock even though Platform may already have accepted the vote. Preserve the broadcast phase explicitly, or conservatively classify every error that can arise after the broadcast boundary as `Unconfirmed` until proved reconciliation resolves it.

In `src/context/dpns_vote_operations.rs`:
- [BLOCKING] src/context/dpns_vote_operations.rs:568-605: Cancellation can overwrite a concurrently claimed target
  Both cancellation methods load operation snapshots while holding the journal mutex, release it, and later reacquire it through `update_dpns_vote_operation`. During that gap the due scheduler and executor can advance the persisted target from `Scheduled` to `Queued` or `Submitting`. The stale snapshot is then written as `NotApplied`; same-operation writes bypass conflict detection, so the lock is released while submission may be in flight or already broadcasting. Perform each read, status check, and conditional transition under one `dpns_vote_operation_guard` acquisition, and only persist when the currently stored status is still `Scheduled`.
- [BLOCKING] src/context/dpns_vote_operations.rs:264-316: Scheduled replacement is not crash-atomic
  Editing a schedule durably changes the old target to `NotApplied` before the replacement operation and index entry are persisted. Each `DetKv::put` is an independent SQLite statement, so the process mutex and error rollback do not protect against termination between writes. A crash in that window leaves the old schedule inactive and the replacement absent or unindexed. The retained legacy row cannot recover it because migration skips any target already present in operation history, including the old `NotApplied` row. Persist the replacement and old-target transition in one storage transaction or one authoritative record mutation.

In `src/context/dpns_vote_state.rs`:
- [SUGGESTION] src/context/dpns_vote_state.rs:63-69: Legacy vote snapshots can be migrated into multiple networks
  The legacy snapshot has no network discriminator, but every network missing its v2 entry copies the same retained v1 value into its namespace. Local masternode identities are loaded globally and reinterpreted for the active network, so switching networks can consume a recent snapshot created on another network. Before refresh completes, this can show an incorrect current choice; if it makes a requested choice appear unchanged, operation construction can discard the target as a no-op and return before the backend refresh runs. Since the source network cannot be established, discard or immediately stale the legacy snapshot instead of copying it into an arbitrary network.

Comment thread src/backend_task/contested_names/vote_on_dpns_name.rs Outdated
Comment thread src/context/dpns_vote_operations.rs Outdated
Comment thread src/context/dpns_vote_operations.rs Outdated
Comment thread src/context/dpns_vote_state.rs Outdated

@thepastaclaw thepastaclaw left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preliminary review — Codex only

All four prior safety findings are fixed, and focused DPNS tests, formatting, and clippy pass. Four blocking correctness issues remain in cold-cache recovery, scheduled-status reporting, schedule-edit result routing, and unavailable preflight handling.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

  • Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
  • Verifier: gpt-5.6-sol — verifier
  • Sonnet: not run (deferred by blocker gate)

🔴 4 blocking

1 additional finding(s) omitted (not in diff).

🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/ui/masternodes/voting_center.rs`:
- [BLOCKING] src/ui/masternodes/voting_center.rs:62-68: Voting Center never adopts refreshed contests
  The center snapshots `ongoing_contested_names()` only during construction, and this result handler only updates the submitted operation ID. If the contest cache is initially empty, `selected_current_states()` is also empty, so no automatic query runs; even if a later `RefreshedDpnsContests` result arrives, `self.contests` remains empty. Step 2 consequently has neither contests nor an in-center refresh action. Reload the contest list when refresh completes and provide a refresh action for the empty state.

In `src/context/contested_names_db.rs`:
- [BLOCKING] src/context/contested_names_db.rs:245-248: Node cards treat terminal failed schedules as pending
  The journal is authoritative, but this summary derives pending state from the legacy mirror's `executed_successfully` flag. That flag is set only after confirmation, so a scheduled target that reaches `Rejected` or `FailedBeforeSubmission` remains false even though its journal lock has been released and it will not be retried. When no contests are open, the node card therefore reports `Vote scheduled` for a terminal failure instead of directing the operator to the failed outcome.

In `src/app.rs`:
- [BLOCKING] src/app.rs:2085-2092: Navigation can strand a successful schedule edit on the temporary ID
  A schedule replacement reuses the existing journal record, so the successful result can contain a different operation ID from the submitted draft. `DpnsVotingCenter::updated_submitted_operation` performs that required translation, but this branch sends the result only to the currently visible root screen. If the operator navigates away while the edit completes, the hidden Masternodes center retains the temporary ID; returning makes it poll a nonexistent record and display `Queuing votes…` indefinitely. Route correlated DPNS results to the Masternodes root screen regardless of visibility.

In `src/context/dpns_vote_operations.rs`:
- [BLOCKING] src/context/dpns_vote_operations.rs:528-530: Unavailable preflight state permanently locks an unsent vote
  This helper only handles a target whose durable status is `Queued`, before `claim_dpns_vote_target` advances it to `Submitting` and before any nonce or network work. An unavailable current-vote refresh therefore cannot mean the vote was broadcast, yet the code persists `Unconfirmed`. Execution then reloads the operation, finds no queued work, returns success, and allows a scheduled sweep to emit `ScheduledVoteSweepCompleted` and retire its preserved cutoff. Reconciliation leaves an absent or mismatched vote unconfirmed, permanently locking a target DET never submitted. Restore scheduled targets to `Scheduled` or mark immediate targets `FailedBeforeSubmission`, and propagate the preflight failure so deferred schedules remain retryable.

Comment thread src/ui/masternodes/voting_center.rs Outdated
Comment thread src/app.rs
Comment thread src/context/dpns_vote_operations.rs Outdated
Base automatically changed from docs/platform-wallet-migration-design to v1.0-dev July 16, 2026 23:29
lklimek and others added 14 commits July 17, 2026 06:38
Define authoritative vote state, a shared quick and bulk composer,
durable operation coordination, safe post-broadcast recovery, and
scheduled-vote consolidation before implementation begins.

Co-Authored-By: Codex GPT-5 <noreply@openai.com>

<sub>🤖 Co-authored by [Claudius the Magnificent](https://github.com/lklimek/claudius) AI Agent</sub>
Load proved current votes, coordinate durable target-level operations, serialize same-node submissions, reconcile ambiguous results without rebroadcasting, and route quick, bulk, and scheduled voting through one reviewed Voting Center.

Co-Authored-By: Codex GPT-5 <noreply@openai.com>

<sub>🤖 Co-authored by [Claudius the Magnificent](https://github.com/lklimek/claudius) AI Agent</sub>
Serialize nonce-consuming submissions across independent operations, make the operation journal network-qualified and fail-closed, recover interrupted work conservatively, require fresh proved state, and prevent scheduled terminal outcomes from being rebroadcast.

Co-Authored-By: Codex GPT-5 <noreply@openai.com>

<sub>🤖 Co-authored by [Claudius the Magnificent](https://github.com/lklimek/claudius) AI Agent</sub>
Carry exact DPNS vote choices through the one-shot operator route so bulk review does not silently replace them with defaults.

Co-Authored-By: Codex GPT-5 <noreply@openai.com>

<sub>🤖 Co-authored by [Claudius the Magnificent](https://github.com/lklimek/claudius) AI Agent</sub>
Preserve exact routed choices, require explicit node selection, keep healthy targets usable when another node is blocked, render proved-state uncertainty honestly, and consolidate scheduled-vote management under Masternodes with guarded actions and readable review details.

Co-Authored-By: Codex GPT-5 <noreply@openai.com>

<sub>🤖 Co-authored by [Claudius the Magnificent](https://github.com/lklimek/claudius) AI Agent</sub>
Render and manage scheduled votes from the durable operation journal, retain exact operation correlation for recovery, prevent implicit schedule replacement, report complete mixed outcomes, and preserve explicit unavailable states and target-identifying confirmations.

Co-Authored-By: Codex GPT-5 <noreply@openai.com>

<sub>🤖 Co-authored by [Claudius the Magnificent](https://github.com/lklimek/claudius) AI Agent</sub>
Durably claim due schedules, preserve ambiguous reconciliation locks, order journal writes before compatibility mirrors, and correlate results and pre-journal failures by network and operation.

Co-Authored-By: Codex GPT-5 <noreply@openai.com>

<sub>🤖 Co-authored by [Claudius the Magnificent](https://github.com/lklimek/claudius) AI Agent</sub>
Show a recovery action when no masternodes are available for the shared voting composer.

Co-Authored-By: Codex GPT-5 <noreply@openai.com>
Co-Authored-By: OpenAI GPT-5 Codex <noreply@openai.com>
Keep scheduled vote recovery inside the sweep error boundary so every
failure clears the per-network in-progress latch through the typed handler.

Co-Authored-By: Codex GPT-5 <noreply@openai.com>
Re-drive already queued schedules and restore unavailable scheduled targets
before propagating the pre-submission failure.

Co-Authored-By: Codex GPT-5 <noreply@openai.com>
Refresh hidden voting state from correlated results, expose contest refresh,
and derive node schedule outcomes from the operation journal.

Co-Authored-By: Codex GPT-5 <noreply@openai.com>

@Claudius-Maginificent Claudius-Maginificent left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consolidated code review — DPNS voting unification (4-agent sweep: security-engineer, project-reviewer, qa-engineer, codex-sol)

Overall assessment. A well-architected, genuinely careful feature whose central safety claim holds — the broadcast gate, lock ordering, crash-recovery direction and fail-closed journal reads are all correct, and no double-broadcast path exists. It is undermined by one systemic state-machine defect family: Unconfirmed is written at points that prove nothing was broadcast, and no code path can ever release it, so routine transient failures can permanently strand a node × contest target with UI copy that promises a recovery the backend cannot deliver. Unconfirmed.holds_lock() is true, Review again is gated on statuses Unconfirmed never reaches, and classify_reconciled_vote (mod.rs:92-97) still has no path to NotApplied — so once a target lands there, it stays there for the life of the contest.

Two further material, independent defects: "Cast Now" is a silent no-op that reports success (the Scheduled → Queued transition is applied to a detached in-memory copy and discarded by the journal reload before dispatch), and cancellation can report success after losing a race to the due-vote sweep, letting an "cancelled" vote proceed to irreversible on-chain submission.

No CRITICAL/HIGH findings — everything is bounded to the DPNS voting subsystem, MEDIUM severity ceiling. 9 of 33 findings are blocking (violate the PR's own shipped requirements or regress base behaviour); the rest are real but non-blocking (per-frame KV scans in the render path, unbounded journal growth, dead fields, tautological tests, i18n fragment concatenation).


Process notes for this review pass

This report was built against 9dc8820 and the PR head has since moved to 541323d3 ("fix: stabilize DPNS voting and SPV reconnect"), touching app.rs, backend_task/error.rs, context/dpns_vote_operations.rs, context/wallet_lifecycle/{spv,tests}.rs, ui/masternodes/{list_screen,voting_center}.rs, wallet_backend/mod.rs, tests/backend-e2e/spv_reconnect.rs. Before posting, every finding whose location fell in a touched file was re-verified against 541323d3 (git diff 9dc8820...541323d3 -- <file> + full-file read):

  • 1 finding dropped as already fixed and already threaded: the never-broadcast-target-locks-forever defect in revalidate_queued_dpns_vote_target (originally reported here as SEC-001) is fixed by the new apply_queued_vote_preflight helper (Checking/Unavailable on a Queued target now → FailedBeforeSubmission, lock released, covered by a new test). This exact defect was independently caught by thepastaclaw's review (comment 3598978018, dpns_vote_operations.rs origin-line 530) and already confirmed fixed there by reply — replied there to note the residual gap instead of reposting. The systemic root cause survives: classify_reconciled_vote (mod.rs:92-97) still never produces NotApplied, and recover_interrupted_dpns_vote_operations still maps a crash during Submitting (i.e. before broadcast) to a permanent Unconfirmed — see the PROJ-001 comment below.
  • 8 findings had their location shifted (code unchanged, only line numbers moved due to unrelated insertions/refactors in the new commit) — corrected line numbers are posted below, each flagged with a drift note.
  • 2 findings excluded from inline posting: CODE-014 (a test-count discrepancy noted during methodology, no source location) and CALL-004 (a walk-scope transparency note, "no action") — both informational, no actionable code location.
  • Dedup against existing threads: cross-checked all 33 surviving findings against the 8 open thepastaclaw review comments on this PR. No genuine duplicates found beyond the SEC-001/dpns_vote_operations.rs:530 case above — thepastaclaw's vote-classification finding (3596869091) describes the opposite failure direction from this report's CALL-001 and doesn't match the current code structure (its cited update_dpns_vote_operation call path has zero callers in this tree), and its cancellation-race finding (3596869097) describes a different mechanism than this report's CODE-005 (a discarded-return-value bug, directly verified still present) — both are posted below as independent findings; a human may want to reconcile the two cancellation-race write-ups.

30 findings are posted as inline comments below.

🤖 Co-authored by Claudius the Magnificent AI Agent

Comment thread src/context/dpns_vote_operations.rs
Comment thread src/ui/masternodes/detail_screen.rs Outdated
Comment thread src/context/dpns_vote_operations.rs Outdated
Comment thread src/context/dpns_vote_operations.rs Outdated
Comment thread src/model/dpns_voting.rs
Comment thread src/backend_task/contested_names/mod.rs Outdated
Comment thread src/model/dpns_voting.rs
Comment thread src/backend_task/contested_names/vote_on_dpns_name.rs
Comment thread src/backend_task/contested_names/mod.rs Outdated
Comment thread src/context/contested_names_db.rs Outdated

@thepastaclaw thepastaclaw left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preliminary review — Codex only

At exact head 541323d, three prior findings are fixed and the scheduled-status finding remains valid. All six supplied Codex findings are confirmed as blocking correctness issues affecting recovery, scheduled execution, cancellation, and truthful UI state. The focused DPNS suite passed 26 tests and the Masternodes kittest subset passed 16 tests, but several tests explicitly preserve the problematic state transitions.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

  • Codex reviewers: gpt-5.6-sol — general (failed), gpt-5.6-sol — general (failed), gpt-5.6-sol — general (completed)
  • Verifier: gpt-5.6-sol — verifier
  • Sonnet: not run (deferred by blocker gate)

🔴 6 blocking

🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/context/contested_names_db.rs`:
- [BLOCKING] src/context/contested_names_db.rs:245-248: Node cards treat terminal failed schedules as pending
  This summary derives pending state from the legacy mirror's `executed_successfully` flag even though the journal is authoritative. Scheduled targets that become `Rejected` or `FailedBeforeSubmission` are not marked executed, so their legacy rows remain false after the journal releases the target lock and stops retrying them. When no contests are open, the node card consequently reports `Vote scheduled` for a terminal failure instead of exposing that the vote needs attention.

In `src/context/dpns_vote_operations.rs`:
- [BLOCKING] src/context/dpns_vote_operations.rs:552-557: A crash before broadcast can permanently lock an unsent vote
  `claim_dpns_vote_target` persists `Submitting` before `submit_dpns_vote` performs the poll query, nonce lookup, signing, or broadcast. A crash during that pre-broadcast window reaches this recovery branch and becomes `Unconfirmed`, which retains the target lock. Reconciliation only changes an exact matching proved vote to `Confirmed`; an absent or different vote leaves the target unconfirmed indefinitely. Recovery needs a durable phase boundary that distinguishes preparation from a transition that may actually have been broadcast.
- [BLOCKING] src/context/dpns_vote_operations.rs:599-604: Cancellation silently succeeds after execution has already claimed the vote
  `cancel_scheduled_target` returns false when the due-vote sweep has already transitioned the target from `Scheduled` to `Queued`, but this wrapper discards that result and returns success. The task handler then deletes the legacy schedule row and returns `Refresh` as though cancellation succeeded, while the journaled vote continues toward submission. Propagate the failed conditional cancellation and remove the legacy row only after the journal cancellation actually wins.
- [BLOCKING] src/context/dpns_vote_operations.rs:277-281: Cancellation is recorded as a proved NotApplied outcome
  The requirements reserve `NotApplied` for definitive post-broadcast reconciliation, but the only current writers of that status are the scheduled-cancellation helpers. The Scheduled tab special-cases the status as `Cancelled`, while Voting activity calls the same target `Not applied` and the operation detail claims DET proved the vote was not applied. Add a distinct cancellation status and reserve `NotApplied` for an authoritative reconciliation result.

In `src/backend_task/contested_names/mod.rs`:
- [BLOCKING] src/backend_task/contested_names/mod.rs:740-764: A failed scheduled sweep leaves queued votes inert until restart
  The sweep durably changes every due target from `Scheduled` to `Queued` before loading voting identities. If that load fails, the task returns with those targets still queued. The one-time recovery latch was already completed before entering the sweep, while subsequent sweeps reconcile only `Unconfirmed` targets and claim only `Scheduled` targets. The UI then displays the queued vote as submitting with cancellation disabled, but no running-process path resumes it; restarting is required.

In `src/ui/masternodes/detail_screen.rs`:
- [BLOCKING] src/ui/masternodes/detail_screen.rs:294-296: The masternode detail view fails open when contest state cannot be read
  The list screen maps a failed summary read to `MasternodeContestSummary::unavailable()`, but the detail constructor and `refresh_contests` use `unwrap_or_default()`. That default reports `Ready` with zero open contests, while `load_open_contests` separately converts its read failure to an empty list. The detail page therefore renders a zero-count header and states that no contests are open when storage is actually unavailable, potentially hiding a vote that needs action. Preserve explicit unavailable state for both the summary and contest list.

Comment thread src/context/contested_names_db.rs Outdated
Comment thread src/context/dpns_vote_operations.rs Outdated
Comment thread src/backend_task/contested_names/mod.rs Outdated
Comment thread src/context/dpns_vote_operations.rs Outdated
Comment thread src/ui/masternodes/detail_screen.rs Outdated
Comment thread src/context/dpns_vote_operations.rs
@lklimek
lklimek force-pushed the feat/dpns-voting-unified branch from 541323d to 1f186ea Compare July 17, 2026 17:50

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 8

🧹 Nitpick comments (1)
src/wallet_backend/mod.rs (1)

2570-2588: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

Open the lock file outside the polling loop.

Opening the lock file inside the polling loop executes a blocking file-system operation on the async executor every 10 milliseconds. Moving the OpenOptions::new()...open() call outside the loop avoids repeatedly blocking the worker thread while waiting for the release barrier.

♻️ Proposed refactor
-    loop {
-        let lock_file = match std::fs::OpenOptions::new()
-            .read(true)
-            .write(true)
-            .create(true)
-            .truncate(false)
-            .open(&lock_path)
-        {
-            Ok(file) => file,
-            Err(error) => {
-                tracing::debug!(
-                    error = %error,
-                    lock_path = %lock_path.display(),
-                    "SPV lock file not openable during release barrier; treating the data directory as unlocked"
-                );
-                return Ok(());
-            }
-        };
+    let lock_file = match std::fs::OpenOptions::new()
+        .read(true)
+        .write(true)
+        .create(true)
+        .truncate(false)
+        .open(&lock_path)
+    {
+        Ok(file) => file,
+        Err(error) => {
+            tracing::debug!(
+                error = %error,
+                lock_path = %lock_path.display(),
+                "SPV lock file not openable during release barrier; treating the data directory as unlocked"
+            );
+            return Ok(());
+        }
+    };
+
+    loop {
         match lock_file.try_lock() {
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/wallet_backend/mod.rs` around lines 2570 - 2588, Move the lock-file
OpenOptions/open call out of the polling loop in the teardown logic, preserving
its existing error handling and early-proceed behavior. Store the successfully
opened file before entering the loop, then reuse it for each lock-status poll so
the loop only performs the nonblocking wait/check operation.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/ai-design/2026-07-16-dpns-voting-experience/01-requirements.md`:
- Around line 3-5: Update the Status section in the requirements document to
identify the specification as implemented or shipped, and remove the statement
that no implementation is authorized. Preserve the surrounding requirements
content.

In `@src/backend_task/contested_names/vote_on_dpns_name.rs`:
- Around line 208-221: Update the mark_dpns_vote_broadcast call in
classify_vote_attempt so its error is converted into
DpnsVoteAttempt::Unconfirmed with the original error attached, rather than
propagated as Err. Preserve the successful path into Vote::wait_for_response and
ensure broadcast-success failures remain eligible for reconciliation instead of
retry.

In `@src/context/dpns_vote_state.rs`:
- Around line 213-225: The cache_confirmed_dpns_vote method must not set the
aggregate snapshot’s available flag or updated_at when confirming a single poll.
Replace this partial update with a full proved-state refresh after confirmation,
or use per-poll availability/freshness tracking so only vote_poll_id is updated
without promoting unrelated cached votes.

In `@src/model/dpns_voting.rs`:
- Around line 104-146: Ambiguous Released votes must not become immediately
resubmittable. In src/model/dpns_voting.rs lines 104-146, update
DpnsVoteTargetStatus::is_reviewable or lock handling so Released remains
non-reviewable until authoritative non-application is proven. Reconcile the
behavior in docs/ai-design/2026-07-16-dpns-voting-experience/01-requirements.md
lines 143-146, 02-ux-spec.md lines 184-222, 03-test-case-spec.md lines 56-66,
04-development-plan.md lines 111-116 and 172-173, and docs/user-stories.md lines
738-742: constrain manual release, define Released/Cancelled safely, add
duplicate-submission coverage, and remove claims that retry is safe while the
outcome is unknown.

In `@src/ui/masternodes/detail_screen.rs`:
- Around line 865-869: Update the contest transformation around
dpns_vote_poll_id so failures no longer discard the contest via filter_map.
Construct an unavailable ContestVoteRow for contests without a poll ID, preserve
the existing refresh action, and provide a user-facing error stating what
happened and how the user can refresh or retry.

In `@src/ui/masternodes/voting_center.rs`:
- Around line 684-686: Update the Err branch in the voting-center journal
handling to stop rendering error.to_string() directly. Show a brief actionable
user-facing message via MessageBanner, and attach the original error as
technical details using BannerHandle::with_details().
- Around line 164-181: Update for_scheduled_edit and the related build_review
flow so editing a scheduled vote preserves the original absolute timestamp
instead of recalculating its offset from a fresh Utc::now(). Store the timestamp
or freeze the offset anchor when initializing node_timing, and ensure
build_review reuses that preserved value without schedule drift during review.
- Around line 125-150: Update DpnsVoteWorkspace::new to handle failures from
load_local_voting_identities and ongoing_contested_names through MessageBanner
rather than unwrap_or_default. Preserve the error details, attach a
MessageBanner for each failed store read, and retain an explicit degraded-state
flag while returning a degraded Self instead of treating failures as valid empty
collections.

---

Nitpick comments:
In `@src/wallet_backend/mod.rs`:
- Around line 2570-2588: Move the lock-file OpenOptions/open call out of the
polling loop in the teardown logic, preserving its existing error handling and
early-proceed behavior. Store the successfully opened file before entering the
loop, then reuse it for each lock-status poll so the loop only performs the
nonblocking wait/check operation.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 9541ec92-bb24-4b54-b679-9859f626a7a9

📥 Commits

Reviewing files that changed from the base of the PR and between 3b32bed and 6a7bf9b.

📒 Files selected for processing (32)
  • docs/ai-design/2026-07-16-dpns-voting-experience/01-requirements.md
  • docs/ai-design/2026-07-16-dpns-voting-experience/02-ux-spec.md
  • docs/ai-design/2026-07-16-dpns-voting-experience/03-test-case-spec.md
  • docs/ai-design/2026-07-16-dpns-voting-experience/04-development-plan.md
  • docs/user-stories.md
  • src/app.rs
  • src/backend_task/contested_names/mod.rs
  • src/backend_task/contested_names/query_dpns_contested_resources.rs
  • src/backend_task/contested_names/vote_on_dpns_name.rs
  • src/backend_task/error.rs
  • src/backend_task/mod.rs
  • src/context/contested_names_db.rs
  • src/context/dpns_vote_operations.rs
  • src/context/dpns_vote_state.rs
  • src/context/mod.rs
  • src/context/wallet_lifecycle/spv.rs
  • src/context/wallet_lifecycle/tests.rs
  • src/model/contested_name.rs
  • src/model/dpns_voting.rs
  • src/model/mod.rs
  • src/ui/components/dpns_subscreen_chooser_panel.rs
  • src/ui/dpns/dpns_contested_names_screen.rs
  • src/ui/masternodes/card.rs
  • src/ui/masternodes/detail_screen.rs
  • src/ui/masternodes/list_screen.rs
  • src/ui/masternodes/mod.rs
  • src/ui/masternodes/voting_center.rs
  • src/ui/state/dpns_vote_workspace.rs
  • src/ui/state/mod.rs
  • src/wallet_backend/mod.rs
  • tests/backend-e2e/spv_reconnect.rs
  • tests/kittest/masternode_tab.rs
💤 Files with no reviewable changes (1)
  • src/ui/components/dpns_subscreen_chooser_panel.rs

Comment thread docs/ai-design/2026-07-16-dpns-voting-experience/01-requirements.md
Comment thread src/backend_task/contested_names/vote_on_dpns_name.rs
Comment thread src/context/dpns_vote_state.rs
Comment thread src/model/dpns_voting.rs Outdated
Comment thread src/ui/masternodes/detail_screen.rs Outdated
Comment thread src/ui/masternodes/voting_center.rs Outdated
Comment thread src/ui/masternodes/voting_center.rs Outdated
Comment thread src/ui/masternodes/voting_center.rs Outdated
@Claudius-Maginificent

Copy link
Copy Markdown
Collaborator

@/tmp/pr901-comment.md

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

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

⚠️ Outside diff range comments (1)
src/ui/dpns/dpns_contested_names_screen.rs (1)

998-1002: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Reset the refresh state when an error clears the banner.

A failed refresh leaves refreshing_status as Refreshing, so the empty-state Refresh button ignores subsequent retries.

Proposed fix
 if matches!(message_type, MessageType::Error | MessageType::Warning) {
     self.refresh_banner.take_and_clear();
+    self.refreshing_status = RefreshingStatus::NotRefreshing;
 }
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/ui/dpns/dpns_contested_names_screen.rs` around lines 998 - 1002, Update
display_message so when an Error message clears refresh_banner, it also resets
refreshing_status from Refreshing to its idle/non-refreshing state, allowing the
empty-state Refresh button to be used for subsequent retries. Preserve the
existing warning behavior and banner-clearing side effect.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/backend_task/contested_names/mod.rs`:
- Line 650: Update the recovery sweep around scheduled_vote_is_resumable so
targets left in Submitting or Confirming after a terminal journal persistence
failure are recovered without requiring restart. Retry terminal persistence or
add ownership-aware recovery for these orphaned in-flight targets, while
preserving existing Queued, Unconfirmed, and resumable-vote handling; add
fault-injection coverage for failures after claim and broadcast.

---

Outside diff comments:
In `@src/ui/dpns/dpns_contested_names_screen.rs`:
- Around line 998-1002: Update display_message so when an Error message clears
refresh_banner, it also resets refreshing_status from Refreshing to its
idle/non-refreshing state, allowing the empty-state Refresh button to be used
for subsequent retries. Preserve the existing warning behavior and
banner-clearing side effect.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 33f30cbe-7d0b-4451-8e3b-237326ef4929

📥 Commits

Reviewing files that changed from the base of the PR and between 6a7bf9b and 35cb542.

📒 Files selected for processing (12)
  • docs/ai-design/2026-07-16-dpns-voting-experience/01-requirements.md
  • src/app.rs
  • src/backend_task/contested_names/mod.rs
  • src/backend_task/contested_names/vote_on_dpns_name.rs
  • src/backend_task/mod.rs
  • src/context/dpns_vote_operations.rs
  • src/context/dpns_vote_state.rs
  • src/model/dpns_voting.rs
  • src/ui/dpns/dpns_contested_names_screen.rs
  • src/ui/masternodes/detail_screen.rs
  • src/ui/masternodes/list_screen.rs
  • src/ui/masternodes/voting_center.rs
💤 Files with no reviewable changes (1)
  • src/backend_task/mod.rs
🚧 Files skipped from review as they are similar to previous changes (8)
  • docs/ai-design/2026-07-16-dpns-voting-experience/01-requirements.md
  • src/backend_task/contested_names/vote_on_dpns_name.rs
  • src/context/dpns_vote_state.rs
  • src/app.rs
  • src/model/dpns_voting.rs
  • src/ui/masternodes/voting_center.rs
  • src/ui/masternodes/detail_screen.rs
  • src/ui/masternodes/list_screen.rs

Comment thread src/backend_task/contested_names/mod.rs Outdated
lklimek and others added 2 commits July 22, 2026 07:40
…d Unconfirmed votes

- Migrate valid legacy operations while parking foreign-network rows outside
  the active legacy index so scheduled sweeps keep making progress.
- Corroborate a proved-different vote across two reconciliation passes before
  marking it NotApplied and releasing the target lock.

Fixes PR review threads CMT-4 and CMT-5 (findings by claude[bot]).

Co-Authored-By: OpenAI Codex <noreply@openai.com>
…them

migrate_legacy_operations previously overwrote the legacy index with an
always-empty retained list, silently discarding foreign-network rows instead
of keeping them for a subsequent correct-network migration pass.

<sub>🤖 Co-authored by [Claudius the Magnificent](https://github.com/lklimek/claudius) AI Agent</sub>

Co-Authored-By: Claude GPT-5 Codex <noreply@anthropic.com>
@Claudius-Maginificent

Copy link
Copy Markdown
Collaborator

Ran a full re-verification pass on the 7 threads that were showing "Unresolved" (independent code reads + tests, not trusting prior diffs):

  • CMT-1 / CMT-2 (broadcast phase boundary, thepastaclaw) — confirmed already fixed by 8335bf94.
  • CMT-3 (immediate/mixed-operation pruning, thepastaclaw) — confirmed already fixed by 8335bf94.
  • CMT-6 (current-vote state read from SQLite every frame) — confirmed already fixed by dd81c468 (now cached via DpnsVoteStateSnapshot).
  • CMT-7 (dead legacy voting UI) — confirmed resolved, not by deletion but by reactivation: c7e6ac41 wired Scheduled Votes and the bulk-schedule popup into the shipped Review-and-cast flow, so the code the review flagged as dead is now the live path.
  • CMT-4 (poisoned cross-network legacy row blocks the scheduled-vote sweep forever) — was still genuinely broken. Pushed 8ca7635a to quarantine the offending row instead of aborting the batch, then caught (via independent QA re-check) that this introduced a new silent data-loss regression: the quarantined id was being wiped from the legacy index instead of retained for a later correct-network pass. Fixed in a follow-up, 76c0ed71.
  • CMT-5 (NotApplied unreachable, proved-different vote locks forever) — was still genuinely broken. Pushed 8ca7635a: a proved-different choice now requires two corroborating post-broadcast reconciliation passes (immune to stale pre-broadcast reads) before transitioning to NotApplied and releasing the lock.

New regression tests added for both real fixes; dpns_vote_operations and contested_names test scopes plus clippy (--all-features --all-targets -D warnings) all pass clean on 76c0ed71.

🤖 Co-authored by Claudius the Magnificent AI Agent

@lklimek lklimek added the claudius-review Triggers automated code review using claudius plugin, runs as a CI job label Jul 22, 2026

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Claudius reviews PR #901feat(dpns): unify safe masternode voting operations

I dispatched four specialists across ~9,200 changed lines in 29 files, then verified every prior-round concern against the current HEAD (76c0ed71) rather than taking the changelog's word for it. Credit where it's due: all three high-priority findings from the last round are genuinely fixed — the fail-closed legacy-journal blast radius now quarantines foreign rows, NotApplied is reachable and releases its lock, and the per-frame render-path DB read is gone in favour of an in-memory snapshot. Double-broadcast safety, network isolation, typed errors, and secret hygiene all hold up. This is a clean, well-tested rewrite, not a broken one.

That said, three MEDIUM items are worth your attention before merge (inline):

  • CODE-001 (blocking)masternode_contest_summary still loops the singular per-contest vote-state read on every Masternodes-list reload, reintroducing the exact O(open-contests)-reads pattern that this PR's own requirement VOTE-NFR-007 forbids and that you eliminated everywhere else. The regression test guards the primitive, not this consumer.
  • SEC-001 — an unreadable journal record fail-closes read-only DPNS browsing (not just voting) with no in-app recovery, and the error copy promises a fix action the UI doesn't offer. Quarantine the bad row the way you already do for cross-network legacy rows.
  • CODE-002is_open_for_voter advertises voter-scoped semantics but ignores its voter_id argument, backed by two tautological tests that assert on a field the function never reads.

No CRITICAL or HIGH findings. The remaining 9 LOW / 1 INFO items (vestigial my_votes / transition_hash fields, a missing post-broadcast fault-injection case, a tautological scheduling test, a stale requirements-doc status banner, minor convention nits) are non-blocking cleanups — full breakdown in the review report. Withholding approval solely on the three MEDIUM threads above; clear those and this is ready to ship.

🤖 Co-authored by Claudius the Magnificent AI Agent

Comment thread src/context/contested_names_db.rs Outdated
Comment thread src/backend_task/contested_names/mod.rs
Comment thread src/model/contested_name.rs Outdated
@github-actions

Copy link
Copy Markdown
Contributor

📊 View full HTML review report

@github-actions github-actions Bot removed the claudius-review Triggers automated code review using claudius plugin, runs as a CI job label Jul 22, 2026
lklimek and others added 4 commits July 22, 2026 16:15
…storage read per node

`masternode_contest_summary` called the singular `dpns_current_vote_state`
once per open contest, each re-reading the same per-node proved snapshot —
O(open-contests) KV reads per node on every Masternodes-list refresh, the
exact pattern VOTE-NFR-007 / VOTE-TC-005 forbid and that the batched
`dpns_current_vote_states` primitive already exists to avoid.

Resolve every open contest's vote-poll id up front, then read all states with
a single `dpns_current_vote_states` call. A read failure degrades each contest
to `Unavailable`, preserving the prior per-contest fallback semantics. Also
collapses the duplicated `is_open_for_voter` filter into one pass.

Adds a regression test that drives the masternode-card consumer (not just the
primitive) and asserts exactly one snapshot read for five open contests.

Co-Authored-By: Claude Opus <noreply@anthropic.com>
…unified

# Conflicts:
#	src/backend_task/contested_names/query_dpns_contested_resources.rs
#	src/context/contested_names_db.rs
Map Platform's typed vote-limit rejection to a dedicated user-facing
TaskError while preserving the SDK source for diagnostics.

Co-Authored-By: Codex GPT-5.6 <noreply@openai.com>

@thepastaclaw thepastaclaw left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preliminary review — Codex only

At exact head f60b7ae, four prior findings are fixed and the obsolete masternode-detail finding is outdated, but two prior scheduled-vote blockers remain. The Scheduled Votes screen also remains dependent on the non-authoritative legacy mirror, while its cleanup path has two history-retention issues and the new Active-contests renderer performs substantial model cloning and poll-ID recomputation on every frame.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

  • Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
  • Verifier: gpt-5.6-sol — verifier
  • Sonnet: not run (deferred by blocker gate)

🔴 3 blocking | 🟡 3 suggestion(s)

1 additional finding(s) omitted (not in diff).

🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/ui/dpns/dpns_contested_names_screen.rs`:
- [BLOCKING] src/ui/dpns/dpns_contested_names_screen.rs:1486-1492: Cancellation silently succeeds after execution has already claimed the vote
  The Scheduled Votes Remove control dispatches `DeleteScheduledVote`, which deletes only the legacy mirror. It never calls `CancelScheduledDpnsVote`, so the journal-authoritative target remains `Scheduled` and the periodic sweep can still queue and submit it after the row disappears. The repaired conditional cancellation wrapper therefore does not protect this user-facing path, including the race where the sweep claims the target after the button is enabled but before the backend task runs. Route journal-backed rows through `CancelScheduledDpnsVote` and delete the mirror only after the guarded journal transition succeeds.
- [BLOCKING] src/ui/dpns/dpns_contested_names_screen.rs:2131-2157: Scheduled Votes still treats the legacy mirror as authoritative
  Refresh rebuilds the Scheduled Votes table exclusively from `get_scheduled_votes()`, even though scheduling first commits the operation journal and explicitly tolerates failure to write that compatibility mirror. A successfully journaled schedule can therefore remain executable without appearing anywhere the operator can cancel it. The status overlay does not repair this mismatch: `DpnsVoteOperationSnapshot::target_status` indexes only lock-holding states, so a surviving mirror whose journal target is `Rejected`, `FailedBeforeSubmission`, or `Cancelled` is reconstructed as `NotStarted` and shown as Pending after refresh or restart. Build scheduled rows and their typed statuses from the authoritative operation journal, using the legacy table only for migration compatibility.
- [SUGGESTION] src/ui/dpns/dpns_contested_names_screen.rs:537-552: Active contests clone their complete nested model every frame
  `render_active_contests` clones every `ContestedName` before filtering or grouping on each egui frame. Each clone copies candidate names, contestant vectors, and the per-contest vote map. Grouping then reconstructs and hashes a Platform poll identifier for every contest, and open cards repeat that computation in availability and proved-vote helpers. This leaves frame-rate heap work proportional to the complete contest payload despite the PR's goal of removing render-path freezes. Cache a lightweight card view model with its poll ID during construction or explicit refresh, or render through stable indices or references without cloning the nested data.

In `src/app.rs`:
- [BLOCKING] src/app.rs:2825-2837: Successful scheduled sweeps leave cached voting views stuck in progress
  Sweep completion refreshes only `visible_screen_mut()`. If Active contests received `ScheduledVotesInProgress` and was then covered by a screen on the stack, this refresh targets the covering screen instead of the hidden DPNS root. The hidden-result router handles `DpnsVoteOperationUpdated` and `RefreshedDpnsContests`, but not `ScheduledVoteSweepCompleted`, while the sweep discards each operation's update result. An ordinary `PopScreen` performs no refresh, so it can reveal targets still cached as queued and disabled after execution has finished. Route sweep completion to the hidden Active-contests root or preserve and forward the individual operation updates.

In `src/context/dpns_vote_operations.rs`:
- [SUGGESTION] src/context/dpns_vote_operations.rs:323-332: The scheduled-vote clear action also deletes immediate voting history
  The pruning predicate admits every complete operation containing only immediate targets because the non-scheduled side of the condition is always true. This behavior is explicitly exercised by the pruning test, but the only production caller is the Scheduled Votes action whose confirmation says it removes completed scheduled votes while pending votes remain. Activating it therefore also deletes unrelated immediate operations shown under Recent voting activity without telling the user. Either restrict this cleanup to operations associated with the removed scheduled rows or rename and relocate the action so its broader history deletion is explicit.

In `src/context/identity_db.rs`:
- [SUGGESTION] src/context/identity_db.rs:1147-1157: A failed prune leaves completed schedules permanently unprunable
  Executed legacy rows are deleted before journal pruning, and the identities of those rows exist only in the local `removed_scheduled_votes` set. If voter-index cleanup, the dirty-marker write, operation deletion, or index rebuilding fails after a mirror was deleted, the method returns with that deletion already persisted. A retry cannot reconstruct the set because the mirror is gone, so the corresponding terminal scheduled operation no longer satisfies the pruning predicate and remains indefinitely. Derive retry eligibility from durable state or persist a cleanup marker before deleting the mirrors.

Comment thread src/app.rs
Comment thread src/ui/dpns/dpns_contested_names_screen.rs Outdated
Comment thread src/context/dpns_vote_operations.rs
Comment thread src/context/identity_db.rs Outdated
Comment thread src/ui/dpns/dpns_contested_names_screen.rs

@thepastaclaw thepastaclaw left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preliminary review — Codex only

At exact head aff18b2, the latest merge adds no new in-scope DPNS defect, and five earlier lifecycle findings remain fixed or obsolete. Three blocking issues remain: schedule removal can leave executable journal targets behind, hidden Active-contests state can remain stale after a sweep, and Scheduled Votes still derives its rows from a best-effort compatibility mirror instead of the authoritative journal. Two non-blocking cleanup issues also remain.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

  • Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
  • Verifier: gpt-5.6-sol — verifier
  • Sonnet: not run (deferred by blocker gate)

🔴 3 blocking | 🟡 2 suggestion(s)

1 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/backend_task/contested_names/mod.rs`:
- [BLOCKING] src/backend_task/contested_names/mod.rs:221-256: Scheduled-vote removal can hide votes that remain executable
  The row-level Remove action dispatches `DeleteScheduledVote`, whose handler deletes only the legacy compatibility row and never calls the guarded journal cancellation at lines 239-256. A journal target that is still `Scheduled` therefore remains eligible for the authoritative sweep after disappearing from the UI, including when the sweep queues it between rendering the enabled button and executing the task. Clear All has the related failure mode: it cancels only targets still in `Scheduled`, ignores targets already advanced to `Queued`, and then clears every mirror row, hiding any vote whose execution already started. Removal must be reported from the durable state machine, not independently from its compatibility mirror.

In `src/app.rs`:
- [BLOCKING] src/app.rs:2825-2837: Hidden Active-contests state can remain stale after a scheduled sweep
  `cast_due_scheduled_votes` discards each operation's `DpnsVoteOperationUpdated` result at `src/backend_task/contested_names/mod.rs:913-924` and emits only `ScheduledVoteSweepCompleted`. This branch refreshes only the currently visible screen, while `dpns_result_needs_hidden_active_contests_route` does not route sweep completion to the hidden Active-contests root. If Active contests receives the preceding queued state and is then covered by a stack screen or another root before completion, its cached snapshot can retain a lock-holding status after the journal is terminal. A plain `PopScreen` does not refresh the revealed screen, so the user can return to stale, disabled voting controls.

In `src/context/dpns_vote_operations.rs`:
- [SUGGESTION] src/context/dpns_vote_operations.rs:316-332: Clearing completed schedules also deletes immediate voting history
  For every immediate target, the predicate's non-scheduled branch is unconditionally true. The Scheduled Votes action labeled `Clear completed scheduled votes` therefore deletes every complete immediate-only operation as well as complete mixed operations whose scheduled rows were removed. Those records provide the Active-contests `Recent voting activity` history, so an action whose confirmation promises to remove completed scheduled votes silently removes unrelated immediate-vote outcomes. Restrict pruning to schedule-only records or rename and relocate the action so its broader history-cleanup behavior is explicit.

In `src/context/identity_db.rs`:
- [SUGGESTION] src/context/identity_db.rs:1143-1157: A partial cleanup can leave completed schedules permanently unprunable
  Successfully deleted mirror rows are remembered only in the local `removed_scheduled_votes` set. If voter-index cleanup or journal pruning fails after a mirror deletion but before the corresponding journal record is deleted, the method returns with that deletion already durable. On retry, the missing mirror row can no longer repopulate the set, so the terminal scheduled operation no longer satisfies the pruning predicate and remains indefinitely unless the same node and contest later acquire another removable schedule. Derive pruning eligibility from durable journal state, persist cleanup intent before deleting mirrors, or make the related mutations transaction-like.

Comment thread src/backend_task/contested_names/mod.rs
Comment thread src/app.rs
Comment thread src/context/dpns_vote_operations.rs Outdated
Comment thread src/context/identity_db.rs Outdated
lklimek and others added 6 commits July 27, 2026 10:20
…el check

Rename the voter-scoped-looking helper to is_votable, remove its unused voter parameter, update the sole caller, and replace voter-map-dependent tests with exhaustive contest-state coverage.

Co-Authored-By: Codex GPT-5 <noreply@openai.com>
…tests root

dpns_result_needs_hidden_active_contests_route() was missing
ScheduledVoteSweepCompleted from its matches!, so the general hidden-route
dispatcher (route_dpns_vote_result_to_hidden_active_contests, called
unconditionally for every Success result) never refreshed a hidden
RootScreenDPNSActiveContests after a scheduled-vote sweep completed. A user
who navigated away or had a screen pushed on the stack while a sweep was
in flight could return to stale, disabled voting controls after a plain
PopScreen.

Also narrows the sweep-completion branch's direct visible_screen_mut()
refresh so it only fires when Active-contests is actually the visible
screen (no screen-stack, no other root selected) instead of unconditionally
refreshing whatever screen happens to be visible.

Adds scheduled_vote_sweep_completion_routes_when_active_contests_is_hidden
covering both the hidden and visible cases.

Co-Authored-By: Codex Sol <noreply@openai.com>
Makes the operation journal authoritative over the legacy scheduled-vote
KV mirror for removal, Clear All, and terminal-operation pruning:

- remove_scheduled_dpns_vote(): guarded row removal that changes a
  Scheduled target to Cancelled and persists before touching the mirror,
  refuses to touch the mirror while a target is Queued/Submitting/
  Confirming/Unconfirmed (returns DpnsScheduledVoteAlreadyStarted), and
  only allows mirror-only deletion when no journal operation still holds
  the target lock.
- clear_all_scheduled_dpns_votes(): guarded Clear All that cancels
  Scheduled targets, retains mirror rows for anything still in flight,
  and returns a typed per-target DpnsScheduledVoteClearOutcome instead of
  unconditionally wiping every mirror row.
- insert_dpns_vote_operation_with_scheduled_mirror(): serializes the
  journal write and the best-effort compatibility-mirror write under the
  same guard, closing the race where a concurrent Clear All could cancel
  and prune a schedule before its mirror row ever landed.
- prune_terminal_dpns_vote_operations(): now takes no removed-set
  parameter and derives eligibility from a durable raw-key enumeration of
  surviving mirror rows instead of an in-memory BTreeSet, so a crash or
  I/O failure partway through cleanup no longer permanently strands a
  terminal operation as unprunable. The predicate also no longer treats
  "not scheduled" as automatic pruning grounds, so immediate-only
  operations backing Recent voting activity survive a scheduled-only
  clear.
- clear_executed_scheduled_votes(): rewritten around the durable
  raw-key helper, propagates row-read errors instead of silently
  treating them as absent, and calls the new no-arg pruning method.
- operation_for_scheduled_vote(): prefers the lock-holding operation,
  falling back to the newest terminal one, instead of first-match.

New model types (src/model/dpns_voting.rs): DpnsScheduledVoteKey,
DpnsScheduledVoteClearDisposition, DpnsScheduledVoteClearOutcome.
New BackendTaskSuccessResult::ScheduledVotesCleared variant.

UI wiring (journal-first Scheduled Votes table, button dispatch, Active
contests render cache) is a separate follow-up commit — this pass is
scoped to the backend_task/context layer only, per the DET module
placement policy.

Co-Authored-By: Codex Sol <noreply@openai.com>
Builds on 4058b04b's guarded backend layer to close out the UI-side gaps:

- Scheduled Votes table rows are now built from the newest journal
  outcome per (voter, contested_name) via DpnsVoteOperationSnapshot::
  scheduled_vote_rows(), falling back to the legacy mirror row only when
  no journal pair exists. A journaled-but-unmirrored schedule is no
  longer invisible, and a terminal journal status (Rejected/
  FailedBeforeSubmission/Cancelled) is no longer misdisplayed as Pending.
- Row Remove dispatches CancelScheduledDpnsVote (guarded journal
  cancellation) for journal-backed rows, and DeleteScheduledVote
  (legacy-only deletion) only for true fallback rows with no journal
  entry.
- Cast-now/Remove availability follows the journal's DpnsVoteTargetStatus
  instead of the old mirror-derived ScheduledVoteCastingStatus; pending
  Cast-now clicks are deduplicated locally until the journal catches up.
- ScheduledVotesCleared now gets a real result-handling arm: routes
  through the hidden-Active-contests mechanism when appropriate, shows a
  success/information MessageBanner summarizing cleared vs. still-in-
  flight targets, and rebuilds the Scheduled Votes rows immediately
  instead of silently doing nothing (previously swallowed by a wildcard
  match arm on both app.rs and the screen's display_task_result).
- Active-contests render path now builds an ActiveDpnsContestSnapshot
  once per construction/refresh (Arc-wrapped contests, poll ID computed
  once each) instead of cloning every ContestedName and rehashing its
  poll ID from three separate call sites every egui frame.

QA follow-ups from independent review of 4058b04b:
- remove_scheduled_dpns_vote(None, ...) — the actual production path
  used by DeleteScheduledVote — now has test coverage for both the
  unlocked (mirror deleted) and locked (refused) cases; the locked case
  now correctly refuses deletion when a journal lock exists.
- Removed the redundant durable mirror-key scan in
  prune_terminal_operations that computed and immediately discarded a
  duplicate KV enumeration.

Co-Authored-By: Codex Sol <noreply@openai.com>
DPNSScreen::display_task_error() cleared the progress overlay and the
pending operation id when a vote submission failed, but left
bulk_vote_handling_status on CastingVotes/SchedulingVotes. That status is
what show_review_and_cast_window() uses as operation_in_progress, and it
disables the Submit button *and* the Cancel button; the egui::Window has
no close control either. Only display_task_result() ever moved the status
out of the in-flight state, so a failed submission left the modal frozen
on "Submitting votes…" with no way to retry, cancel, or dismiss it — and
the state survives navigating away and back, since the screen instance is
kept in AppState::main_screens.

Reproduces whenever the backend task returns Err after dispatch, e.g.
DpnsCurrentVoteUnavailable: the screen's cached proved-vote snapshot is
fresh enough to build targets, then the backend's pre-submission
refresh_dpns_vote_states() fails against an unreachable DAPI.

Move the status to Failed(<error text>) alongside the existing overlay
cleanup, gated on the same clear_vote_overlay_on_error ownership check so
an unrelated task error cannot disturb a submission still in flight. The
window already renders Failed inline and re-enables both buttons, and
TaskError's Display is the user-facing text by convention.

Adds failed_submission_releases_the_review_window (covers both in-flight
statuses) and unrelated_error_keeps_the_pending_submission_in_progress.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

@thepastaclaw thepastaclaw left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preliminary review — Codex only

At exact head fcbc1dc, four of the five required prior findings are fixed, but mixed immediate/scheduled batches still lose their immediate history during scheduled-vote cleanup. The journal-first changes also leave row-level Remove unable to remove journal-backed rows, which is a blocking regression in a core Scheduled Votes action; manual cast correlation and per-frame activity cloning remain non-blocking issues.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

  • Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
  • Verifier: gpt-5.6-sol — verifier
  • Sonnet: not run (deferred by blocker gate)

🔴 1 blocking | 🟡 2 suggestion(s)

1 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/context/dpns_vote_operations.rs`:
- [BLOCKING] src/context/dpns_vote_operations.rs:991-1041: Remove cannot remove a journal-backed scheduled vote
  For a `Scheduled` target, Remove persists `Cancelled` and deletes only the compatibility mirror. For an already-terminal target, it leaves the journal outcome unchanged and again deletes only the mirror. The journal-first projection in `DpnsVoteOperationSnapshot::scheduled_vote_rows` includes every scheduled-timing outcome, including `Cancelled`, `Confirmed`, and failed outcomes, and prefers that outcome over the mirror. The refresh returned by the removal task therefore reconstructs the same row immediately, and clicking Remove again reaches the terminal branch without changing that result. Add a durable per-target dismissal/removal state, or prune only the selected journal target while preserving unrelated targets and history in the same operation.

In `src/ui/dpns/dpns_contested_names_screen.rs`:
- [SUGGESTION] src/ui/dpns/dpns_contested_names_screen.rs:2126-2174: Unrelated vote activity can finish a manual scheduled cast
  `CastScheduledVote` maps to `BackendTaskContext::Other`, so a manual Cast now overlay has no `pending_vote_operation`. The fallback at lines 2127-2129 consequently treats any visible task error without a DPNS operation ID, including a periodic `ScheduledVoteSweep` error, as the owner of that overlay. The success fallback at lines 2170-2171 similarly accepts any `DpnsVoteOperationUpdated`, including unattributed reconciliation updates emitted by an overlapping sweep, and both paths clear all pending scheduled-cast keys. This can lower the blocker and re-enable Cast now while the original cast is still running. Give manual scheduled casts a context containing their exact voter/contest key or another dispatch identity, and clear only the matching pending entry.
- [SUGGESTION] src/ui/dpns/dpns_contested_names_screen.rs:863-871: Recent activity deep-clones and sorts all operation history every frame
  `render_voting_activity` calls `to_vec()` on the complete operation snapshot before filtering to five entries. Each clone recursively copies all targets and their owned aliases and contested-name strings, and the full cloned history is then sorted on every egui frame. Immediate-only terminal operations are intentionally retained, so this render cost grows with normal voting history even though only five records are displayed. Select and sort references or lightweight indices, then render only the newest five operations without cloning the stored records.

Comment on lines +991 to +1041
let journal_is_authoritative = match selected {
Some((operation_id, DpnsVoteTargetStatus::Scheduled)) => {
if lock_index
.get(key)
.is_some_and(|owner| *owner != operation_id)
{
return Err(TaskError::DpnsScheduledVoteAlreadyStarted);
}
if !cancel_scheduled_target(&kv, self.network, operation_id, key)? {
return Err(TaskError::DpnsScheduledVoteAlreadyStarted);
}
true
}
Some((
_,
DpnsVoteTargetStatus::Queued
| DpnsVoteTargetStatus::Submitting
| DpnsVoteTargetStatus::Confirming
| DpnsVoteTargetStatus::Unconfirmed,
)) => return Err(TaskError::DpnsScheduledVoteAlreadyStarted),
Some((operation_id, _)) => {
if lock_index
.get(key)
.is_some_and(|owner| *owner != operation_id)
{
return Err(TaskError::DpnsScheduledVoteAlreadyStarted);
}
true
}
None => {
if lock_index.contains_key(key) {
return Err(TaskError::DpnsScheduledVoteAlreadyStarted);
}
false
}
};

let voter = key.voter_id.to_buffer();
if let Err(error) = delete_scheduled_vote_in(&kv, &voter, contested_name) {
if !journal_is_authoritative {
return Err(error);
}
tracing::warn!(
?error,
expected_operation_id = ?expected_operation_id,
voter_id = %key.voter_id,
contested_name,
"Scheduled DPNS vote journal was updated but its compatibility mirror remains"
);
}
Ok(())

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Blocking: Remove cannot remove a journal-backed scheduled vote

For a Scheduled target, Remove persists Cancelled and deletes only the compatibility mirror. For an already-terminal target, it leaves the journal outcome unchanged and again deletes only the mirror. The journal-first projection in DpnsVoteOperationSnapshot::scheduled_vote_rows includes every scheduled-timing outcome, including Cancelled, Confirmed, and failed outcomes, and prefers that outcome over the mirror. The refresh returned by the removal task therefore reconstructs the same row immediately, and clicking Remove again reaches the terminal branch without changing that result. Add a durable per-target dismissal/removal state, or prune only the selected journal target while preserving unrelated targets and history in the same operation.

source: ['codex']

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved in this update — Remove cannot remove a journal-backed scheduled vote no longer present.

Auto-resolved by the review system based on the latest commit diff. If you believe this was closed in error, reopen the thread.

Comment on lines +2126 to +2174
fn display_backend_task_error(&mut self, context: &BackendTaskContext, _error: &TaskError) {
self.clear_vote_overlay_on_error = match self.pending_vote_operation {
Some(operation_id) => dpns_operation_id(context) == Some(operation_id),
None => self.vote_overlay.is_some() && dpns_operation_id(context).is_none(),
};
}

fn display_task_error(&mut self, error: &TaskError) -> bool {
let handled = scheduled_vote_sweep_is_quiet(error);
if matches!(
error,
TaskError::ScheduledVoteRejected { .. }
| TaskError::ScheduledVoteAllAddressesExhausted { .. }
| TaskError::ScheduledVoteResultUnavailable
| TaskError::ScheduledVoteSweepFailed { .. }
| TaskError::ScheduledVoteSweepAllAddressesExhausted { .. }
) {
self.scheduled_vote_cast_in_progress = false;
if let Ok(mut guard) = self.scheduled_votes.lock() {
for vote in guard.iter_mut() {
if vote.1 == ScheduledVoteCastingStatus::InProgress {
vote.1 = ScheduledVoteCastingStatus::Failed;
}
}
self.pending_scheduled_casts.clear();
if self.clear_vote_overlay_on_error {
self.vote_overlay.take_and_clear();
self.pending_vote_operation = None;
self.clear_vote_overlay_on_error = false;
// The review window disables both Submit and Cancel while a
// submission is in flight, so a failed submission must leave that
// state here. Otherwise the window stays on "Submitting votes…"
// with no way to retry or close it.
if matches!(
self.bulk_vote_handling_status,
VoteHandlingStatus::CastingVotes | VoteHandlingStatus::SchedulingVotes
) {
self.bulk_vote_handling_status = VoteHandlingStatus::Failed(error.to_string());
}
}
handled
if let Err(refresh_error) = self.vote_operations.refresh(&self.app_context) {
tracing::warn!(
?refresh_error,
"Could not refresh DPNS voting state after a task error"
);
}
self.rebuild_scheduled_vote_rows();
scheduled_vote_sweep_is_quiet(error)
}

fn display_task_result(&mut self, backend_task_success_result: BackendTaskSuccessResult) {
match backend_task_success_result {
// If immediate cast finished, see if we have pending to schedule next
BackendTaskSuccessResult::DPNSVoteResults(results) => {
let errors: Vec<String> = results
.iter()
.filter_map(|(_, _, r)| r.as_ref().err().map(|e| e.to_string()))
.collect();
let successes: Vec<String> = results
.iter()
.filter_map(|(name, _, r)| r.as_ref().ok().map(|_| name.clone()))
.collect();

if !errors.is_empty() {
let errors_string = errors.join("\n\n");
if !successes.is_empty() {
// partial success
self.bulk_schedule_message = Some((
MessageType::Error,
format!(
"Successes: {}/{}\n\nErrors:\n\n{:?}",
successes.len(),
successes.len() + errors.len(),
errors_string
),
));
} else {
// all failed
self.bulk_schedule_message =
Some((MessageType::Error, format!("Errors:\n\n{}", errors_string)));
BackendTaskSuccessResult::DpnsVoteOperationUpdated { operation_id, .. } => {
self.pending_scheduled_casts.clear();
if let Err(error) = self.vote_state.reload(&self.app_context) {
tracing::warn!(
?error,
"Could not reload proved DPNS vote state after an operation update"
);
}
let owns_result = self.pending_vote_operation == Some(operation_id)
|| (self.pending_vote_operation.is_none() && self.vote_overlay.is_some());
if owns_result {
self.vote_overlay.take_and_clear();
self.pending_vote_operation = None;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Suggestion: Unrelated vote activity can finish a manual scheduled cast

CastScheduledVote maps to BackendTaskContext::Other, so a manual Cast now overlay has no pending_vote_operation. The fallback at lines 2127-2129 consequently treats any visible task error without a DPNS operation ID, including a periodic ScheduledVoteSweep error, as the owner of that overlay. The success fallback at lines 2170-2171 similarly accepts any DpnsVoteOperationUpdated, including unattributed reconciliation updates emitted by an overlapping sweep, and both paths clear all pending scheduled-cast keys. This can lower the blocker and re-enable Cast now while the original cast is still running. Give manual scheduled casts a context containing their exact voter/contest key or another dispatch identity, and clear only the matching pending entry.

source: ['codex']

Comment on lines +863 to +871
fn render_voting_activity(&mut self, ui: &mut Ui) {
let mut operations = self.vote_operations.operations().to_vec();
operations.sort_by_key(|operation| operation.created_at);
let operations = operations
.into_iter()
.rev()
.filter(|operation| !operation.targets.is_empty())
.take(5)
.collect::<Vec<_>>();

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Suggestion: Recent activity deep-clones and sorts all operation history every frame

render_voting_activity calls to_vec() on the complete operation snapshot before filtering to five entries. Each clone recursively copies all targets and their owned aliases and contested-name strings, and the full cloned history is then sorted on every egui frame. Immediate-only terminal operations are intentionally retained, so this render cost grows with normal voting history even though only five records are displayed. Select and sort references or lightweight indices, then render only the newest five operations without cloning the stored records.

source: ['codex']

…unified

# Conflicts:
#	src/ui/masternodes/detail_screen.rs

@thepastaclaw thepastaclaw left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preliminary review — Codex only

At exact head 32032a7, all four indexed prior findings remain valid. The cumulative PR also contains two blocking Active-contests defects that contradict its voting-capability and exact-review requirements, plus two additional vote-state correctness and diagnostic issues; the latest base-branch merge does not resolve these DPNS paths.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

  • Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
  • Verifier: gpt-5.6-sol — verifier
  • Sonnet: not run (deferred by blocker gate)

🔴 3 blocking | 🟡 2 suggestion(s)

4 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/ui/dpns/dpns_contested_names_screen.rs`:
- [BLOCKING] src/ui/dpns/dpns_contested_names_screen.rs:2350-2354: Loaded nodes without voting keys bypass the actionable empty state
  This gate treats any entry in `voting_identities` as voting-capable, but `load_local_voting_identities()` includes every non-User identity without requiring an associated voter identity or signing key. Read-only masternodes therefore bypass the promised "None of your loaded nodes has a voting key" state and enter the composer. Submission later reaches `submit_dpns_vote`, which rejects identities whose `associated_voter_identity` is absent. Filter the composer to identities that can satisfy the submit path, and show the load action when that filtered set is empty.
- [BLOCKING] src/ui/dpns/dpns_contested_names_screen.rs:1597-1607: Review and cast presents no-op nodes as votes that will be cast
  The review sheet says it will cast on behalf of all loaded nodes but lists each contest choice only once. It does not display the required node × contest targets, each node's current choice, or which targets already match the requested choice. Those no-op targets are removed only after Submit by `DpnsVoteOperation::new`, so a mixed-current-state review claims that every node will vote even though some will do nothing. This violates VOTE-FR-024/025 and the PR's stated exact-review behavior. Build and filter the effective target set before rendering, list current choice, requested choice, and timing for every retained target, and explain suppressed no-ops before submission.

In `src/context/dpns_vote_state.rs`:
- [SUGGESTION] src/context/dpns_vote_state.rs:182-245: Concurrent snapshot writers can erase a newly confirmed vote
  Each refresh performs network I/O and then replaces the complete per-voter snapshot, while `cache_confirmed_dpns_vote` performs an unsynchronized read-modify-write of the same record. Backend tasks are spawned independently, and scheduled sweeps execute several operations concurrently, so a refresh that fetched state before a successful vote can finish afterward and overwrite the confirmed cache entry. A subsequent UI reload can present the proved vote as absent, and concurrent read-modify-write updates can also lose entries. Serialize per-voter snapshot writes or attach generations to fetches and reject or merge stale completions; cover the stale-refresh-after-confirmation interleaving with a test.
- [SUGGESTION] src/context/dpns_vote_state.rs:166-230: Best-effort refresh drops the error that blocked vote preflight
  `refresh_dpns_vote_states` logs SDK query failures, stores an unavailable snapshot, and returns `()`. That is suitable for an ambient refresh, but `execute_dpns_vote_operation` also uses it as a mandatory submission preflight. In that path the typed source is discarded and the task returns only `DpnsCurrentVoteUnavailable`. Because that fieldless error contains no DAPI reachability source, the outer contextualizer and operation diagnostics cannot report the transport or exhausted-address failure that actually blocked submission. Return a typed per-voter refresh report or add a strict preflight API that preserves the source while ambient callers explicitly choose best-effort behavior.

Comment on lines +2350 to +2354
let has_any = !self.active_contests.is_empty();
if self.voting_identities.is_empty() {
inner_action |= self.render_no_voting_nodes(ui);
} else if has_any {
self.render_active_contests(ui);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Blocking: Loaded nodes without voting keys bypass the actionable empty state

This gate treats any entry in voting_identities as voting-capable, but load_local_voting_identities() includes every non-User identity without requiring an associated voter identity or signing key. Read-only masternodes therefore bypass the promised "None of your loaded nodes has a voting key" state and enter the composer. Submission later reaches submit_dpns_vote, which rejects identities whose associated_voter_identity is absent. Filter the composer to identities that can satisfy the submit path, and show the load action when that filtered set is empty.

source: ['codex']

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved in cbb4afaLoaded nodes without voting keys bypass the actionable empty state no longer present.

Auto-resolved by the review system based on the latest commit diff. If you believe this was closed in error, reopen the thread.

Comment on lines +1597 to +1607
ui.label(format!(
"Casting on behalf of all my nodes ({count}).",
count = self.voting_identities.len()
));
ui.separator();
ui.heading(format!("Votes to cast ({}):", self.selected_votes.len()));
for vote in &self.selected_votes {
let candidate_name = self.candidate_name(&vote.contested_name, vote.vote_choice);
let choice = review_vote_choice_label(vote.vote_choice, candidate_name.as_deref());
ui.label(format!("• {name}.dash → {choice}", name = vote.contested_name));
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Blocking: Review and cast presents no-op nodes as votes that will be cast

The review sheet says it will cast on behalf of all loaded nodes but lists each contest choice only once. It does not display the required node × contest targets, each node's current choice, or which targets already match the requested choice. Those no-op targets are removed only after Submit by DpnsVoteOperation::new, so a mixed-current-state review claims that every node will vote even though some will do nothing. This violates VOTE-FR-024/025 and the PR's stated exact-review behavior. Build and filter the effective target set before rendering, list current choice, requested choice, and timing for every retained target, and explain suppressed no-ops before submission.

source: ['codex']

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved in cbb4afaReview and cast presents no-op nodes as votes that will be cast no longer present.

Auto-resolved by the review system based on the latest commit diff. If you believe this was closed in error, reopen the thread.

Comment on lines +182 to +245
stream::iter(voters)
.map(|voter| {
let sdk = sdk.clone();
let kv = kv.clone();
let network = self.network;
async move {
let voter_id = voter.identity.id();
match fetch_votes_for_voter(&sdk, voter_id).await {
Ok(votes) => {
let snapshot = StoredCurrentVotes {
available: true,
updated_at: now_ms(),
votes,
};
if let Err(error) = save_snapshot(&kv, network, &voter_id, &snapshot) {
tracing::warn!(
?error,
voter_id = %voter_id,
"Could not save proved DPNS vote state"
);
}
}
Err(error) => {
let snapshot = StoredCurrentVotes {
available: false,
updated_at: now_ms(),
votes: BTreeMap::new(),
};
if let Err(storage_error) =
save_snapshot(&kv, network, &voter_id, &snapshot)
{
tracing::warn!(
?storage_error,
voter_id = %voter_id,
"Could not save unavailable DPNS vote state"
);
}
tracing::warn!(
?error,
voter_id = %voter_id,
"Proved DPNS vote-state query was unavailable"
);
}
}
}
})
.buffer_unordered(4)
.collect::<Vec<_>>()
.await;
}

/// Update the proved-state cache after a confirmed target.
pub(crate) fn cache_confirmed_dpns_vote(
&self,
voter_id: Identifier,
vote_poll_id: Identifier,
choice: ResourceVoteChoice,
) -> Result<(), TaskError> {
let kv = self.det_kv()?;
let mut snapshot = load_snapshot(&kv, self.network, &voter_id)?.unwrap_or_default();
snapshot.available = true;
snapshot.updated_at = now_ms();
snapshot.votes.insert(vote_poll_id.to_buffer(), choice);
save_snapshot(&kv, self.network, &voter_id, &snapshot)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Suggestion: Concurrent snapshot writers can erase a newly confirmed vote

Each refresh performs network I/O and then replaces the complete per-voter snapshot, while cache_confirmed_dpns_vote performs an unsynchronized read-modify-write of the same record. Backend tasks are spawned independently, and scheduled sweeps execute several operations concurrently, so a refresh that fetched state before a successful vote can finish afterward and overwrite the confirmed cache entry. A subsequent UI reload can present the proved vote as absent, and concurrent read-modify-write updates can also lose entries. Serialize per-voter snapshot writes or attach generations to fetches and reject or merge stale completions; cover the stale-refresh-after-confirmation interleaving with a test.

source: ['codex']

Comment on lines +166 to +230
pub(crate) async fn refresh_dpns_vote_states(&self, sdk: &Sdk) {
let voters = match self.load_local_masternode_identities() {
Ok(voters) => voters,
Err(error) => {
tracing::warn!(?error, "Could not load nodes for DPNS vote-state refresh");
return;
}
};
let kv = match self.det_kv() {
Ok(kv) => kv,
Err(error) => {
tracing::warn!(?error, "Could not open DPNS vote-state storage");
return;
}
};

stream::iter(voters)
.map(|voter| {
let sdk = sdk.clone();
let kv = kv.clone();
let network = self.network;
async move {
let voter_id = voter.identity.id();
match fetch_votes_for_voter(&sdk, voter_id).await {
Ok(votes) => {
let snapshot = StoredCurrentVotes {
available: true,
updated_at: now_ms(),
votes,
};
if let Err(error) = save_snapshot(&kv, network, &voter_id, &snapshot) {
tracing::warn!(
?error,
voter_id = %voter_id,
"Could not save proved DPNS vote state"
);
}
}
Err(error) => {
let snapshot = StoredCurrentVotes {
available: false,
updated_at: now_ms(),
votes: BTreeMap::new(),
};
if let Err(storage_error) =
save_snapshot(&kv, network, &voter_id, &snapshot)
{
tracing::warn!(
?storage_error,
voter_id = %voter_id,
"Could not save unavailable DPNS vote state"
);
}
tracing::warn!(
?error,
voter_id = %voter_id,
"Proved DPNS vote-state query was unavailable"
);
}
}
}
})
.buffer_unordered(4)
.collect::<Vec<_>>()
.await;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Suggestion: Best-effort refresh drops the error that blocked vote preflight

refresh_dpns_vote_states logs SDK query failures, stores an unavailable snapshot, and returns (). That is suitable for an ambient refresh, but execute_dpns_vote_operation also uses it as a mandatory submission preflight. In that path the typed source is discarded and the task returns only DpnsCurrentVoteUnavailable. Because that fieldless error contains no DAPI reachability source, the outer contextualizer and operation diagnostics cannot report the transport or exhausted-address failure that actually blocked submission. Return a typed per-voter refresh report or add a strict preflight API that preserves the source while ambient callers explicitly choose best-effort behavior.

source: ['codex']

lklimek and others added 4 commits August 1, 2026 09:05
…es blocked

Three blocking defects in the unified DPNS voting flow.

Review and cast lied about what it would send. It printed one bullet per
contest and a raw node count, so a multi-node batch never showed its real
node x contest targets, the choice already on chain, the per-target timing,
or the targets DpnsVoteOperation::new silently drops as no-ops after Submit.
The sheet and the submit click now share one resolved plan, so the sheet
cannot promise something other than what is sent: every retained target is
listed with node, contest, requested choice, current choice and timing, the
skipped no-op count is stated, the headline counts the effective targets, and
Submit is disabled when nothing would be submitted. No-op suppression now has
a single definition, DpnsVoteTarget::is_no_op, shared by the review and the
operation; the operation still receives the unfiltered list so its no_op_count
keeps driving the post-submit feedback.

Remove on a scheduled vote did not remove it. The cancellation write was
durable and correct, but scheduled_vote_rows projected every scheduled-timing
outcome back into the table including Cancelled, so the row returned on the
next refresh with a second Remove button that did nothing. The projection now
honours the cancellation and drops the row, while keeping the target's pair in
the legacy-suppression set so a mirror row that outlived a best-effort delete
cannot resurrect it. Pruning the journal could not have fixed this: a bulk
schedule is one operation with many targets, so removing one row leaves the
operation incomplete and unprunable. Clear All keeps its bulk prune.

A masternode loaded without its voting key reached the composer and only
failed at submit time with NoVotingIdentity, because the gate filtered on
identity type alone. The DPNS surfaces now keep only identities that satisfy
the submit path (QualifiedIdentity::can_cast_masternode_vote), so a read-only
node lands on the actionable "no voting key" state with Load a masternode
before any vote is composed.

VOTE-FR-024, VOTE-FR-025 and VOTE-TC-013 of the DPNS voting experience design.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The limited-vote-change note belongs to VOTE-FR-015, which is outside the
scope of this blocking-fix pass. The review sheet still lists each target's
current choice, so the operator sees what a vote replaces; only the extra
advisory line and the ReviewPlan predicate behind it are removed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
762c66cf -> 5931df74 for dash-sdk, rs-sdk-trusted-context-provider,
platform-wallet and platform-wallet-storage. Cargo.lock moves only the
platform git source revs; no other dependency drifts.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Claudius-Maginificent

Copy link
Copy Markdown
Collaborator

Pushed an update covering three things since the last commit:

  1. Merged v1.0-dev (clean, no conflicts) to pick up fix(wallet): isolate wallet databases from SPV cache + stop cross-wallet top-up corruption #954.
  2. Fixed the 3 blocking findings from review triage:
    • Review-and-cast sheet now shows exactly what will be cast (per-target requested/current choice/timing, suppressed no-ops counted, headline reflects the effective target set — not raw node count).
    • "Remove" on a scheduled vote now actually removes it (was leaving a dead button after the first click).
    • Read-only/keyless masternodes are blocked from the vote composer up front instead of failing late at submit.
    • 11 new tests, red-first proof included; full evidence in the fix commits.
  3. Bumped the platform dependency pin to PR #3968's latest tip (5931df74) — verified a no-op for us (identical upstream source tree, only platform's own lockfile moved).

🤖 Co-authored by Claudius the Magnificent AI Agent

@thepastaclaw thepastaclaw left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preliminary review — Codex only

At exact head 513af26, the keyless-node gate and exact node-by-contest review findings are fixed. Three blocking defects remain: terminal scheduled rows cannot actually be removed, the required limited-vote-change warning was removed, and an absolute UTC schedule drifts while Review remains open. Six additional in-scope suggestions remain around mixed-history pruning, result correlation, unbounded frame work, vote-state races and diagnostics, and swallowed identity-loading errors.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

  • Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
  • Verifier: gpt-5.6-sol — verifier
  • Sonnet: not run (deferred by blocker gate)

🔴 3 blocking | 🟡 1 suggestion(s)

6 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/ui/dpns/dpns_contested_names_screen.rs`:
- [BLOCKING] src/ui/dpns/dpns_contested_names_screen.rs:1724-1726: Review no longer warns that changing a vote is limited
  The review lists current and requested choices but no longer labels a changed existing vote as consuming a limited vote change. This directly contradicts VOTE-FR-015 and VOTE-TC-006 in the PR's authoritative requirements, and commit a9d5a2c4 removed the predicate, warning, and test that previously enforced the behavior. Restore a warning whenever any effective target replaces an existing proved choice, without claiming a remaining count.
- [BLOCKING] src/ui/dpns/dpns_contested_names_screen.rs:2035-2040: Absolute UTC schedules drift while the review remains open
  `simple_schedule_option()` converts the absolute `Cast on (UTC)` value into a relative day/hour/minute offset only when the option is applied or the field changes. `build_review_plan()` then recreates the persisted timestamp as `Utc::now() + offset` on every frame and again on Submit. If 12:00 is selected at 11:00 and submission happens ten minutes later, the vote is scheduled around 12:10 rather than the chosen time; that can also move it beyond a contest deadline. Preserve the selected absolute timestamp separately, while keeping the advanced `Schedule after` controls relative if intended.
- [SUGGESTION] src/ui/dpns/dpns_contested_names_screen.rs:198-204: Voting identity load failures masquerade as a keyless-node state
  `loaded_voting_identities` converts every typed error from `load_local_voting_identities()` into an empty vector. Both the Active-contests gate and Review window then show `None of your loaded nodes has a voting key` and direct the operator to load another masternode, even when identity storage was unreadable or unavailable. Return the `Result` and surface the actual `TaskError` through a `MessageBanner`; use an empty fallback only after recording the load failure for the user.

Comment on lines +1724 to +1726
if plan.no_op_count() > 0 {
ui.label(review_skipped_line(plan.no_op_count()));
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Blocking: Review no longer warns that changing a vote is limited

The review lists current and requested choices but no longer labels a changed existing vote as consuming a limited vote change. This directly contradicts VOTE-FR-015 and VOTE-TC-006 in the PR's authoritative requirements, and commit a9d5a2c removed the predicate, warning, and test that previously enforced the behavior. Restore a warning whenever any effective target replaces an existing proved choice, without claiming a remaining count.

Suggested change
if plan.no_op_count() > 0 {
ui.label(review_skipped_line(plan.no_op_count()));
}
if plan.no_op_count() > 0 {
ui.label(review_skipped_line(plan.no_op_count()));
}
if plan
.effective()
.any(|entry| entry.target.current_choice.is_some())
{
ui.colored_label(
DashColors::warning_color(dark_mode),
"Changing a vote uses one of this node's limited vote changes. Review the current and requested choices before submitting.",
);
}

source: ['codex']

Comment on lines 2035 to +2040
let offset = chrono::Duration::days(*days as i64)
+ chrono::Duration::hours(*hours as i64)
+ chrono::Duration::minutes(*minutes as i64);
let scheduled_time = (now + offset).timestamp_millis() as u64;

for sv in &self.selected_votes {
let new_vote = ScheduledDPNSVote {
contested_name: sv.contested_name.clone(),
voter_id: identity.identity.id(),
choice: sv.vote_choice,
unix_timestamp: scheduled_time,
executed_successfully: false,
};
scheduled_list.push(new_vote);
}
(
VoteTiming::Scheduled((Utc::now() + offset).timestamp_millis() as u64),
format!("Scheduled in {days} d {hours} h {minutes} min"),

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Blocking: Absolute UTC schedules drift while the review remains open

simple_schedule_option() converts the absolute Cast on (UTC) value into a relative day/hour/minute offset only when the option is applied or the field changes. build_review_plan() then recreates the persisted timestamp as Utc::now() + offset on every frame and again on Submit. If 12:00 is selected at 11:00 and submission happens ten minutes later, the vote is scheduled around 12:10 rather than the chosen time; that can also move it beyond a contest deadline. Preserve the selected absolute timestamp separately, while keeping the advanced Schedule after controls relative if intended.

source: ['codex']

Comment on lines +198 to +204
fn loaded_voting_identities(app_context: &AppContext) -> Vec<QualifiedIdentity> {
app_context
.load_local_voting_identities()
.unwrap_or_default()
.into_iter()
.filter(QualifiedIdentity::can_cast_masternode_vote)
.collect()

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Suggestion: Voting identity load failures masquerade as a keyless-node state

loaded_voting_identities converts every typed error from load_local_voting_identities() into an empty vector. Both the Active-contests gate and Review window then show None of your loaded nodes has a voting key and direct the operator to load another masternode, even when identity storage was unreadable or unavailable. Return the Result and surface the actual TaskError through a MessageBanner; use an empty fallback only after recording the load failure for the user.

source: ['codex']

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants