fix(lite-backend): don't panic on a reorg while a send is pending

invalidate_block unwrapped a note's `spent` field for notes that only had `unconfirmed_spent` set, so any reorg while one of our sends was still in the mempool panicked the backend (and poisoned the wallet lock). The branch could only panic or do nothing; it is gone, and a reorg now leaves `unconfirmed_spent` as it is: the send can still be mined on the new branch, because the chain checks the anchor's root, not its height. The oracle no longer steers reorgs around pending sends: it now reorgs above, across and below the sent tip, including popping the anchor block, and the reproducer runs by default. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-11 06:05:06 -05:00
parent c233d4d503
commit db8d5359a4
2 changed files with 345 additions and 98 deletions
@@ -1867,9 +1867,9 @@ pub fn scan_full_mempool_tx(&self, tx: &Transaction, height: i32, _datetime: u64
                                nd.spent = None;
                            }

-                            if nd.unconfirmed_spent.is_some() && txids_to_remove.contains(&nd.spent.unwrap()) {
-                                nd.unconfirmed_spent = None;
-                            }
+                            // unconfirmed_spent is left as it is: a pending send can still be mined on the
+                            // new branch. Only a block that spends the note (scan_block) or a reload clears
+                            // it, the same as for a send that expires unmined.
                        })
                })
        }