Sweep recovery: detect replaced/conflicting broadcast tx and auto-resync instead of stalling

[parrth20]

Even though #996 exists but this is a follow-up implementation issue that generalizes the fix and avoids being a duplicate by focusing on recovery + correctness guarantees.

Problem
Sweep can stall forever when a broadcast collaborative transaction (TX1) is replaced by another tx (TX2) spending the same inputs. Jam continues waiting for TX1 confirmation, while TX2 confirms. The user then sees confusing jar balances / 0-conf states and may hit bad-txns-inputs-missingorspent.

Goal
Make Sweep robust to tx replacement/conflicts: if TX1 is replaced/evicted and inputs are spent by another tx, Sweep should auto-resync state and either:

continue with the confirmed replacement outcome, or
fail fast with a clear recoverable error + guided action (rescan / refresh / lock-unlock).

Acceptance criteria
If TX1 is replaced by TX2 (same inputs), Sweep does not stall indefinitely.
UI shows a clear state transition: “Detected conflicting/replaced tx → resyncing wallet state…”
After resync, jars/UTXOs reflect the chain result (TX2) without requiring a full service restart.
Logs include a structured event: SWEEP_TX_REPLACED (or similar) with txids + input outpoints.

Repro (regtest/signet)
Start Sweep with collaborative transaction enabled.
Capture TX1 before it confirms.
Broadcast a replacement TX2 spending the same inputs (RBF/conflict path).
Mine blocks confirming TX2.
Observe that Sweep currently waits forever; expected behavior is recovery/resync.

Notes
Jam docs mention scheduled sweeps can take long, but “stuck forever due to confirmed replacement” is distinct and should be detectable.

Ping
@theborakompanioni — I’d like to take this on and submit a PR.

[theborakompanioni]

@parrth20 nice! Absolutely!
I am not sure how a fix will look like. Do you know how such a situation might occur?
In v2 triggering collaborative transactions is currently work in progress. Hope to have it ready soon.
Do you want to backport it to the legacy branch as well?

[parrth20]

@parrth20 nice! Absolutely! I am not sure how a fix will look like. Do you know how such a situation might occur? In v2 triggering collaborative transactions is currently work in progress. Hope to have it ready soon. Do you want to backport it to the legacy branch as well?

@theborakompanioni Thanks! Re: “how might this occur?” — I think there are a few realistic paths:

1. RBF / fee-bump replacement: if the collaborative TX is broadcast as opt-in RBF (or otherwise replaceable), the party controlling the inputs (taker wallet side) can re-broadcast a replacement with the same inputs but different outputs/fee.
2. Mempool eviction → re-broadcast: TX1 can be evicted (low fee / mempool pressure), and then a new TX2 gets created and broadcast spending the same inputs.
3. Concurrent spender / duplicate flow: a second Jam instance or another process using the same wallet can spend those UTXOs while Jam is still in “waiting for TX1 confirm”, creating TX2 and effectively invalidating TX1.

The reason I’m confident this is fixable is: in #996 the funds become correct after a restart, which suggests the “startup resync” path recomputes wallet/UTXO state from the network and reconciles the confirmed TX2. My idea is to make Sweep trigger that same reconciliation automatically when a conflict is detected, instead of waiting forever.

Proposed fix shape (high level):
In the Sweep “wait for confirmation” loop: if TX1 is missing from mempool / not found for some threshold, check the input outpoints.
If any input outpoint is already spent (by any tx): classify TX1 as replaced/conflicted, emit a structured log event (e.g. SWEEP_TX_REPLACED with txid + outpoints + replacement txid if discoverable), and trigger wallet state resync (same mechanism as on restart).
After resync: either continue based on the confirmed outcome (TX2), or fail fast with a clear recoverable message + guidance (refresh/rescan).

On v2: totally fine if collaborative-tx triggering is still WIP — this recovery logic should still be valuable once that path lands.

Backport: I’m happy to implement it on the legacy/release branch first since #996 affects current users, and then port/adjust for v2 if needed. But I can do it the other way around if you prefer.

If this approach matches what you have in mind, should I start working on it now — and which target branch would you like the PR against (legacy vs devel/v2)?

[theborakompanioni]

The reason I’m confident this is fixable is: in #996 the funds become correct after a restart, which suggests the “startup resync” path recomputes wallet/UTXO state from the network and reconciles the confirmed TX2. My idea is to make Sweep trigger that same reconciliation automatically when a conflict is detected, instead of waiting forever.

Proposed fix shape (high level): In the Sweep “wait for confirmation” loop: if TX1 is missing from mempool / not found for some threshold, check the input outpoints. If any input outpoint is already spent (by any tx): classify TX1 as replaced/conflicted, emit a structured log event (e.g. SWEEP_TX_REPLACED with txid + outpoints + replacement txid if discoverable), and trigger wallet state resync (same mechanism as on restart). After resync: either continue based on the confirmed outcome (TX2), or fail fast with a clear recoverable message + guidance (refresh/rescan).

On v2: totally fine if collaborative-tx triggering is still WIP — this recovery logic should still be valuable once that path lands.

Backport: I’m happy to implement it on the legacy/release branch first since #996 affects current users, and then port/adjust for v2 if needed. But I can do it the other way around if you prefer.

If this approach matches what you have in mind, should I start working on it now — and which target branch would you like the PR against (legacy vs devel/v2)?

Hey, thanks for the detailed answer. I think you can try to fix it on the legacy branch - that might give you inside if it is even fixable on the UI side. I'd lead against detecting it at first and offer a way to resync manually. I do not think the sweep process can be paused/resumed with the current state of JM.

If there is a way to detect it, I'd be a great addition for v2 as well!

[parrth20]

hey @theborakompanioni can you please check my PR and tell me if any changes are recommended, now it's been 2 days since i have made my PR

and is there any other issue where i can contribute.

[theborakompanioni]

hey @theborakompanioni can you please check my PR and tell me if any changes are recommended, now it's been 2 days since i have made my PR

I am sorry I have not yet had the time for a review and it will take even more time to reproduce and test everything.

and is there any other issue where i can contribute.

I'd say take a look at the v2 branch. You can create tickets for everything you think it important to be addressed. There is still a bunch of missing functionality. Afterwards, there needs to be a refactoring and clean-up, e.g. remove duplicate code, split into reusable components, UI cleanup and simplification, addressing all TODOs, etc.

[parrth20]

I'd say take a look at the v2 branch. You can create tickets for everything you think it important to be addressed. There is still a bunch of missing functionality. Afterwards, there needs to be a refactoring and clean-up, e.g. remove duplicate code, split into reusable components, UI cleanup and simplification, addressing all TODOs, etc.

Hey @theborakompanioni please go through my recent PR in V2 branch.

[parrth20]

I'd say take a look at the v2 branch. You can create tickets for everything you think it important to be addressed. There is still a bunch of missing functionality. Afterwards, there needs to be a refactoring and clean-up, e.g. remove duplicate code, split into reusable components, UI cleanup and simplification, addressing all TODOs, etc.

Hey @theborakompango please go through my recent PR in V2 branch.

[parrth20]

I'd say take a look at the v2 branch. You can create tickets for everything you think it important to be addressed. There is still a bunch of missing functionality. Afterwards, there needs to be a refactoring and clean-up, e.g. remove duplicate code, split into reusable components, UI cleanup and simplification, addressing all TODOs, etc.

Hey @theborakompango please go through my recent PR in V2 branch.

@theborakompanioni please reopen this issue... i did a misclick
sorry for inconvenience