This seems to be a general extension of the problem that was addressed in #2159.
A transfer in flight is anchored to a specific transaction, and the porter watches that transaction's txid for confirmation. If a different transaction confirms instead, spending one or more of the same inputs, the original anchored tx can never confirm, but, since the porter is watching only its id, nothing tells it to stop waiting. From tapd's perspective, the transfer remains pending indefinitely.
Opus (Fable, we hardly knew ye), tells me that this can still happen in a couple of scenarios:
- A remote channel party claims an HTLC ahead of our timeout sweep.
- The transaction was already confirmed when we restart, but lnd rejects the rebroadcast (ErrDoubleSpend) before the porter has re-registered to learn of it.
I think the first case is relatively benign (it was the remote party's anyway), but I think we lose track of our own outputs in the second case. The fix is to use the same mechanism introduced in #2159, i.e. "if another confirmed tx spent the outputs, the tx we're watching will never confirm":
- While waiting for confirmation, watch the inputs in parallel (covers the HTLC race and any other foreign claim).
- When our own broadcast is rejected as a double spend, interrogate the chain to decide whose tx won (covers ErrDoubleSpend-on-restart).
This seems to be a general extension of the problem that was addressed in #2159.
A transfer in flight is anchored to a specific transaction, and the porter watches that transaction's txid for confirmation. If a different transaction confirms instead, spending one or more of the same inputs, the original anchored tx can never confirm, but, since the porter is watching only its id, nothing tells it to stop waiting. From tapd's perspective, the transfer remains pending indefinitely.
Opus (Fable, we hardly knew ye), tells me that this can still happen in a couple of scenarios:
I think the first case is relatively benign (it was the remote party's anyway), but I think we lose track of our own outputs in the second case. The fix is to use the same mechanism introduced in #2159, i.e. "if another confirmed tx spent the outputs, the tx we're watching will never confirm":