Sweep stuck if transaction is replaced by another one

[offcast-dev]

The Problem:

When using Jam Sweep function (scheduler) the transaction was stuck for a long time with 0 confirmations. Originally was reported in Jam repo, reporting here as it could be a backend problem.

Expected behavior

Scheduler should continue even if the collaborative transaction is, for some reason, replaced by another one.

Actual behavior

When performing a Sweep, it was stuck at the first transaction for 24h. After stopping the Sweep, I noticed that the balance minus the fee is sitting in the Apricot Jar with 0 confirmations for many hours; the miner fee was high enough to go through. Sending funds to a different Jar errored with "-25 bad-txns-inputs-missingorspent". After restarting the service, the funds appeared in the Blueberry Jar with ~100 confirmations.

Unfortunately I cannot provide logs from Jam UI, as it happened too long ago. But here is what I was able to get from the logs. The first transaction (let's call it TX1) was successfully created, signed with all parties, and broadcasted to the network. Jam removed 3 UTXO that were inputs to TX1 and created 1 UTXO from the output of TX1 that pointed to Apricot Jar. For some reason, TX1 was replaced by a different transaction TX2 that had the same inputs but different outputs. TX2 was mined, but Jam was waiting for TX1 to be mined, which would never happen because TX2 had replaced TX1. That's why the Sweep was stuck, and Apricot showed balance with 0conf. After restarting the service, Jam picked up the TX2 and the outputs that were pointing to the Blueberry Jar.

Steps to reproduce the problem

Start collaborative transaction
While it is not mined replace it with another one
Specifications

Version: 0.4.1-1
Platform: StartOS 0.3.5-1
Browser: Tor 15.0.3