client/dcr: restarting dexc mid-trade results in stuck trade

[norwnd]

I'm observing this issue pretty consistently when restarting dexc mid-trade (right after Taker swap): #2042 (comment)

I've looked a bit into it and think it more likely has to do with the following being out of sync than with reorgs, something like:

• when dexc starts, trades are pulled from DB and redemption search starts (through FindRedemption method findRedemptionQueue gets filled)
• dcr spv wallet starts in parallel to this ^ and inspects blocks that keep coming in monitorBlocks, it seems to be doing some time-based delays (at least I don't see obvious way it's synched with 1st process from above)

so when dexc restarts (perhaps with several minutes delay), it misses the block we are interested in (or a whole range of blocks maybe) would be my guess ... but I give up this investigation, leaving this in case somebody wants to pick it up.

[chappjc]

Is it revoked? Shouldn't be searching for a redemption unless the match is revoked.
Can you provide a specific repro?

[norwnd]

Trade DCR-USDC with self (on testnet) such that DCR swap txn is done as 2nd step, wait until DCR swap txn is broadcasted (show up at dcrdata explorer) and restart dexc (seems like there is no need to even wait before starting it again),

now we can navigate to Taker and Maker match cards, both point of view on Taker DCR swap (after restart, same as before restart) is that confirmations are stuck at 0:

while dcrdata shows 4 confirmations at this point (and they keep growing over time ofc):

Is it revoked?

I don't think it's revoked, see Status=settling(Taker Swap Sent), I think it gets revoked eventually and funds are refunded, but I'm not sure I understand/agree with that:

Shouldn't be searching for a redemption unless the match is revoked.

revoked or not, Maker can redeem; hence Taker must be ready to redeem right ? never mind, I meant that if Maker redeems Taker won't know and will keep trying to refund, from what I've gathered.

To sum up, there seems to be 2 undesirable outcomes from this dexc mid-trade restart:

• (if we are Maker) trade is stuck and then refunded
• (if we are Taker) trade is stuck and then refunded, or worse we might never redeem

observing with dcr spv wallet, but haven't tested for other wallets.

[norwnd]

Now that match is revoked on both sides, it looks like this (more restarts don't change anything):

my understanding: Maker should be trying (and succeeding) to redeem, but it doesn't and I see this in logs:

2023-07-20 08:39:42.927 [INF] CORE: Match 898cdf9d705b9febb59dfbc82db8b56619417d4a200ed73ef42e6459e3355875 not yet redeemable: current confs = 0, required confs = 1

[chappjc]

It's not consistent, but I did reproduce it twice. PR just for debugging, with a possible workaround: #2444
However, there seems to be a bug in dcrwallet/wallet/udb that keeps the transaction unconfirmed.