fix(wallet): surface unresolved Platform funding transfers

[lklimek]

TL;DR: Integrate Core-to-Platform funding into ordinary Dash Core transaction rows, with details and recorded payment conflicts. Recovered historical funding is not presented as a pending transfer. New payments stop before signing when confirmed history contradicts the wallet’s available funds. Cancellation and verified Platform delivery checks remain unavailable.

User story

As a wallet user, I want to find an interrupted transfer in my transaction history and understand what the wallet actually knows about it.

Scenario

Base flow

A transfer to Platform does not receive confirmation, and the user reopens the wallet.

Actual behavior

The pending entry sorts below dated payments, and the history does not explain a competing payment using the same funds.

Expected behavior

The transfer appears once inside Dash Core Transactions, with its confirmation status, a Details action, and any recorded input conflict. Historical funding stays in chronological history. The user can distinguish local records from verified delivery information.

Detailed discussion

What was done

• Before signing a Core payment or new asset lock (including identity, Platform-address, and shielded funding), compare live funding outpoints against persisted confirmed transaction inputs. Fail closed on conflicts or unreadable records; existing asset-lock continuation is unchanged. The check reads technical records retained across visible-history resets.
• Platform dependencies track Platform fix/pr-5126 at c0425f7bdcc29776f6d5f0f35a56cde7eb368c7f, including its rust-dashcore pin 18f7f3e6, for persisted Core transaction accounting reconciliation and confirmed-spend restoration on SQLite load. Document field handling supports the new typed-array and key-reference variants; identity balance lookup failures retain typed error classification. This is an unmerged upstream dependency. The SQLite loader replays confirmed records through the wallet checker and restores finality before sync checkpoint pruning, preventing old funding from resurrecting spent outputs. It uses dash_async::block_on with no additional executor. DET's preflight remains enabled. The new InvitationNetworkMismatch error is handled in the existing exhaustive error classifiers.
• Full resync durably clears the selected wallet’s displayed transaction history. Wallet-scoped reset markers prevent old rows from returning after restart; verified block observations rebuild history even when upstream skips finalized record events. Technical Core records are retained for spend accounting, along with reservations and Platform transfer state. This is a history reset, not transaction cancellation. Interrupted scans require Full resync again.
• Merge tracked funding and hydrated Core history by TXID. Keep funding-only records visible, sort unconfirmed rows first, and retain confirmed rows in date order.
• Classify RecoveredFromChain separately: unknown Platform consumption does not establish an unfinished transfer. Keep transfer information in transaction history, without a separate review summary or View transfers shortcut.
• Group Copy, View, Details, and disabled cancellation in the final Actions column, using the existing compact button style.
• Group Import key, Refresh, Full resync, and Testnet-only Get test DASH under Advanced.
• Full resync rewinds only the selected HD wallet’s Core filter checkpoint to genesis through the upstream manager API, off the async executor. It preserves wallet records and requires Core to be connected and synced. A blocking overlay reuses the initial-sync progress and cancellation flow. It stays up until the selected wallet reaches its target and the Core pipeline is synced, including the interval before fresh sync status arrives. Matching task completion/failure clears it; unrelated results cannot dismiss it. The request must be repeated after an app restart if the scan was interrupted.
• Use the existing Refresh action to reload transfer records after wallet refresh completes, retaining one follow-up read when an earlier read is in flight. There is no separate record-refresh button.
• Show funding information in row details, with optional Core explorer links and explicit unknown recipient/Platform outcome.
• Show a disabled Cancel transfer action for unconfirmed funding with the backend limitation explained; do not imply that deleting records returns funds.
• Use scoped async assessments, request coalescing, timeout handling, and stale wallet/network/request rejection. Close details on wallet/network changes.
• Keep doctests in the main CI suite only, and use Cargo directly for test execution.

Limits

The preflight is a conservative wallet-wide consistency check, not an atomic selected-input check or proof against unknown spends. An inconsistent output can block an otherwise fundable payment. It does not repair the live UTXO set, cancel existing transactions, or release reservations.

Automatic conflict cleanup already exists upstream through TransactionsSwept, and DET handles those events. The missing operation is safe reconciliation/cancellation of historical conflicts found only in persisted DET history; the signed, unsent Core-payment abandonment API cannot substitute for it.

The pinned wallet lacks verified finalized ancestry, atomic conflict reconciliation, durable asset-lock cancellation/rebroadcast control, and verified consumption lookup for every recovered lock. Safe cancellation, automatic reconciliation, and verified continuation remain WAL-034 gaps. No timeout-based release, record deletion, fund movement, or new secret storage is introduced.

Validation

• Follow-up on the three non-configuration E2E failures: the targeted run passed DashPay profile registration and the full shielded lifecycle (withdrawal raised to 50,000,000 credits); TC-018 still fails with AssetLockAddressNotFound after matching the exact new TXID and duff amount. Diagnostics show a valid tracked lock/proof but no credit-output address in DET's Wallet::known_addresses; the manual funding path's local key lookup remains a production gap. The fixture now waits for final, unreserved asset-lock inputs instead of counting unconfirmed display funds, polls shielded balance propagation with a timeout, and recovers leftover test funds before enforcing the suite budget. The historical DashPay failure was not reproduced with detailed telemetry; the premature-readiness bug is confirmed in code. Existing finality unit test and scoped backend E2E Clippy passed.
• Current pin: formatting and cargo clippy --locked --test backend-e2e --all-features -- -D warnings pass. The upstream fix restores confirmed spend/finality state; rust-dashcore is unchanged.
• Upstream regression was reproduced before the fix; 47 targeted storage tests now pass, including 8 restart/finality/reservation regressions. Loading a private copy of the existing E2E database restored 38 wallets with zero live UTXO/confirmed-history conflicts. The framework wallet restored 14 UTXOs and 10.74146576 DASH, versus the earlier inflated 105.03792631 DASH.
• Live testnet validation on DET 2383a0aa2 / Platform c0425f7bdc / rust-dashcore 18f7f3e6: the standalone Core payment round trip passed; the full network-dependent backend E2E run finished with 65 passed and 10 failed (75 executed, 18 non-network tests filtered out). Seven failures require the unset E2E_MN_PAYOUT_KEY; the other failures were DashPay identity funding (AssetLockInsufficientFunds), shielded withdrawal (balance mismatch), and asset-lock address funding (AssetLockAddressNotFound). Core payment round trip and cold-process wallet migration/balance recovery passed. No WalletConfirmedInputConflict occurred in this run. The suite is not green; the three other failures have not been root-caused.
• cargo test --lib spend_history --all-features: regression covers rejection through the payment entrypoint before signing, history reset, wallet/outpoint isolation, pending records, unchanged live funds, and corrupt-record failure.
• Reproduced the UI regression before fixing it: no Unconfirmed row in the Core table.
• cargo test --lib pending_transfers --all-features: 16 passed, including merge/order, recovered-history semantics, Refresh ordering, and light/dark/narrow-layout UI tests. Layout assertions cover final-column placement, button ordering and equal height, horizontal scrolling, and opening details at 420 px.
• cargo test --test kittest wallets_screen --all-features: 18 passed.
• cargo test --lib full_resync --all-features: 5 passed, including durable history reset, failed persistence, selected-wallet isolation, block replay, preservation of upstream records, selected-wallet checkpoint rewind, preservation of other wallets, unknown wallets, disconnected/busy rejection, and overlay completion/cancellation while the previous status remains Synced.
• cargo test --test kittest task9_spv --all-features: 2 passed, covering initial-sync blocking and keyboard-safe cancellation.
• cargo test --lib advanced_ --all-features: 15 passed, including popup interaction in both themes, wallet action availability, and faucet exclusion on Mainnet.
• Scoped local Clippy (--all-features --lib --tests -- -D warnings) and cargo fmt --all passed.
• Live Testnet diagnosis was read-only. The reported transaction remains unconfirmed in local history, and 31 funding records of 0.01 DASH are marked recovered_from_chain. Explorer evidence confirms the recorded competing spend; it is not used to authorize cancellation.
• Original user wallet files were inspected read-only. Authorized fund-moving tests use the isolated backend-e2e testnet wallet/configuration.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[thepastaclaw]

🕓 Review not started yet because this PR is a draft.

• Request normal review — click when the PR is ready for review.
• Request priority review — click to move this review to the front of the queue.

Commit 83ad4c2. Normal review starts when eligible; priority review starts as soon as a slot is available.