key-wallet: mark_instant_send_utxos can downgrade a mined record to InstantSend, erasing its block height — ChainLock promotion then skips it forever #1020

Expected Behavior

An InstantSend lock applied to a transaction the wallet already holds as InBlock or InChainLockedBlock (or has already finalized) keeps the block context and its BlockInfo, the same way check_core_transaction already treats it. A later ChainLock at or above that height promotes the record to InChainLockedBlock.

Current Behavior

WalletInfoInterface::mark_instant_send_utxos overwrites the record's context unconditionally:

and TransactionRecord::update_context is a plain assignment with no ordering guard:

TransactionContext::InstantSend(InstantLock) carries no BlockInfo, so the record's height() becomes None:

apply_chain_lock only promotes InBlock records and intentionally skips InstantSend, so a downgraded record is never promoted again, however far the chain advances:

The same transition through check_core_transaction is already guarded — an IS lock on a transaction that is finalized or is_confirmed() is ignored ("Only accept IS transitions for unconfirmed transactions"):

mark_instant_send_utxos has no equivalent guard. It is reached from WalletManager::process_instant_send_lock:

which dash-spv's mempool manager calls only while the transaction is still in its mempool map; otherwise the lock is parked in pending_is_locks and later re-applied through the guarded check_core_transaction path:

So in steady state the unguarded overwrite is not a routine path. It is reachable in the ordering window between the wallet applying a block that contains the transaction and the mempool manager evicting it (remove_confirmed, driven by SyncEvent::BlockProcessed) — an IS lock that arrives in that window reaches mark_instant_send_utxos for an already-mined record. Any future caller of the public trait method inherits the same hazard.

Visible symptom downstream: ChainLockProcessed with no locked transactions for the affected record, and consumers that need a mined height for it (for example rs-platform-wallet's asset-lock ChainLock proof) wait for a promotion that cannot happen.

Possible Solution

Make mark_instant_send_utxos mirror the guard in wallet_checker.rs (L202-L212): skip the context update when account.transaction_is_finalized(txid) or record.is_confirmed(). Whether the UTXOs should still be flagged IS-locked and the conflict sweep still run in that case is a maintainer call; the sweep is harmless for a mined transaction.

A more general option is a guard inside update_context that refuses to move from a block context back to Mempool / InstantSend; that would also cover the re-broadcast re-sighting downgrade described in dashpay/platform#4238, but touches more callers. Keeping the InstantLock on a mined record is the reverse-direction problem in #763 and can be solved together.

Wallets already in this state are repaired on the consumer side (dashpay/platform, ticket 32167); this change stops new records from entering it.

Steps to Reproduce

Unit-level, no network needed:

1. Record a wallet-owned transaction with TransactionContext::InBlock(BlockInfo { height: H, .. }).
2. Apply its InstantLock — in a key-wallet-manager unit test via process_instant_send_lock (private; see event_tests.rs for an in-crate caller), or by calling the WalletInfoInterface::mark_instant_send_utxos trait method directly.
3. Observe: the record's context is InstantSend(_) and height() is None.
4. Call apply_chain_lock(H + 10): the record is not in the promoted list and stays InstantSend.

For comparison, feeding the same lock through process_mempool_transaction(&tx, Some(lock)) (→ check_core_transaction) leaves the record InBlock at height H.

Context

• Found while triaging Dash Wallet iOS support ticket 32167: a Core→Shielded transfer whose asset lock can never get a ChainLock proof, because the funding record is InstantSend with no height. Whether this overwrite is how that wallet got there is not proven; the code allows it only through the ordering window described above, so there is no routine path to look for.
• Nothing open changes this path: fix(key-wallet, dash-spv): re-emit late knowledge — record corrections, durable rescans, address-pool repair #979 and the other open key-wallet PRs do not touch mark_instant_send_utxos or update_context.
• Related: Found-021: TransactionRecord::update_context silently drops InstantLock on InBlock/InChainLockedBlock promotion #763 (reverse direction — promotion to a block context drops the InstantLock), Asset-lock ChainLock finality wait has no per-record promotion and no cancellation — stuck locks unrecoverable, app shutdown hangs platform#4238 (asset-lock ChainLock wait with no per-record promotion).

Your Environment

• rust-dashcore dev @ 0da39ebfd716fb47e11a4ac1bdd9a68da27ead16; identical for the cited files at e4208c90786a6854bd498315bcb571ef24182c15, the revision pinned by dashpay/platform v4.2-dev.
• Steps verified with the unit test below, added to key-wallet-manager/src/event_tests.rs (reuses its setup_manager_with_wallet, create_tx_paying_to, make_block, dummy_instant_lock helpers). cargo test -p key-wallet-manager --lib verify_ -- --nocapture at 0da39ebf (the run also printed the context after each step; those println!s are omitted from the code below):

after block: ctx=block 2000 height=Some(2000)
after process_instant_send_lock: ctx=instant send height=None
ChainLockProcessed locked_transactions: [{}]
after apply_chain_lock(2010): ctx=instant send height=None
after process_mempool_transaction(tx, Some(lock)): ctx=block 2000 height=Some(2000)
test result: ok. 2 passed; 0 failed

fn bip44_context(
    manager: &WalletManager<ManagedWalletInfo>,
    wallet_id: &WalletId,
    txid: &Txid,
) -> Option<(TransactionContext, Option<u32>)> {
    manager
        .get_wallet_info(wallet_id)
        .unwrap()
        .accounts
        .standard_bip44_accounts
        .get(&0)
        .unwrap()
        .transactions()
        .get(txid)
        .map(|r| (r.context.clone(), r.height()))
}

#[tokio::test]
async fn verify_late_is_lock_downgrades_mined_record() {
    let (mut manager, wallet_id, addr) = setup_manager_with_wallet();
    let wallets = BTreeSet::from([wallet_id]);
    let tx = create_tx_paying_to(&addr, 0x67);
    let block = make_block(vec![tx.clone()], 0x67, 1_500);
    manager.process_block_for_wallets(&block, block.block_hash(), 2_000, &wallets).await;
    let (ctx, h) = bip44_context(&manager, &wallet_id, &tx.txid()).expect("record");
    assert!(matches!(ctx, TransactionContext::InBlock(_)));
    assert_eq!(h, Some(2_000));

    manager.process_instant_send_lock(dummy_instant_lock(tx.txid()));
    let (ctx, h) = bip44_context(&manager, &wallet_id, &tx.txid()).expect("record");
    assert!(matches!(ctx, TransactionContext::InstantSend(_)));
    assert_eq!(h, None);

    manager.apply_chain_lock(ChainLock::dummy(2_010));
    let (ctx, _) = bip44_context(&manager, &wallet_id, &tx.txid()).expect("record still stored");
    assert!(matches!(ctx, TransactionContext::InstantSend(_)));
}

#[tokio::test]
async fn verify_check_core_transaction_path_keeps_block_context() {
    let (mut manager, wallet_id, addr) = setup_manager_with_wallet();
    let wallets = BTreeSet::from([wallet_id]);
    let tx = create_tx_paying_to(&addr, 0x68);
    let block = make_block(vec![tx.clone()], 0x68, 1_500);
    manager.process_block_for_wallets(&block, block.block_hash(), 2_000, &wallets).await;

    manager.process_mempool_transaction(&tx, Some(dummy_instant_lock(tx.txid()))).await;
    let (ctx, h) = bip44_context(&manager, &wallet_id, &tx.txid()).expect("record");
    assert!(matches!(ctx, TransactionContext::InBlock(_)));
    assert_eq!(h, Some(2_000));
}