Swap refunds aren't assigned to their received vaults
My thanks to Heimdall for alerting me to that refunds are deliberately assigned to the inbound-received vault without carrying out vault selection code (Discord thread of relevance).
refundTx
has an ObservedTx as its second argument, and here uses that ObservedTx's ObservedPubKey as a TxOutItem's VaultPubKey before calling TryAddTxOutItem
for that TxOutItem.
Usually refundTx
is called with a full ObservedTx, but for the swap queue (and equivalent code for the order book) refundTx
is called with and ObservedTx empty except for the Tx field, notably with an empty VaultPubKey field
(thus choosing initial vault assignment with the vault selection code).
The bottom of #1423 (closed)'s description covers how the vault selection code failed for both a swap and its refund, resulting in the inbound funds being swallowed by the vaults. This is a problem which requires vault selection code modification (for which !2644 (merged) is an existing suggested fix), but it is notable that the refund failure would not have happened if the inbound-received vault were initially assigned as for other refundTx
instances.
My current impression is that even if a refund were assigned to a retired vault, after 300 blocks of no outbound it would be assigned to a different available vault (as long as one had a sufficiently large balance?).
My proposal at this time is to use GetObservedTxInVoter
to retrieve the full (consensus) ObservedTx, going ahead with the current code (using the Tx directly from the message) if unable to retrieve.