You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is possible for Swap transaction to get stuck for 8+ hours (and/or never get mined),
I'm not sure what happens in case such Swap transaction does get mined eventually - I'm assuming Bison wallet will realize it needs to refund it ASAP and will send a Refund transaction (for Maker that's safe behavior, for Taker that's safe until 20h into the Match),
but what happens in case such Swap transaction never gets mined is - corresponding Match ends up in a hanging state where "it thinks Swap happened" (even thought it actually didn't) and "it thinks Refund is coming" (even though Bison wallet cannot possibly refund it since there is nothing to refund); all the while wallet also thinks Swap transaction is pending in mempool (which is technically correct but might be confusing to a User, so it's probably best to clean it up after Match state is resolved one way or another), here is how such stuck Match looks like:
I think there are at least two different ways this can be addressed:
(optimistic) just do nothing until certain timestamp in the future, and then simply clean-up Match and wallet Swap transaction pending in mempool; that's simple but could be naive in case Swap transaction does get mined eventually against all the odds
(proper) or instead issue a so-called Cancel transaction spending Swap funding coin forcefully to make sure Swap transaction never comes back to life guaranteed (perhaps only after network fees have dropped and are reasonably low)
Another note, #3131 also probably depends on the resolution of this issue since Swapping balance (under Locked section) keeps showing funds reserved by stuck Swap transaction even after I've sent another Polygon transaction with the same nonce that got mined (effectively replacing/invalidating that Swap transaction completely) - which is probably due to corresponding Match still expecting Refund that will never happen.
Another aspect of this issue - it seems bumping fee for Swap transaction for EVM-based assets (through manual user-action request) isn't working correctly because if Swap tx1 was replaced by tx2 (with higher fee) Match won't know about it and we keep trying to convince server tx1 is the Swap transaction to look for (we do refund Swap tx2 successfully in that case though, that's good 👍 )
it seems Redeems/Refunds would suffer from exactly the same issue of Match being unaware of fee-bumped transaction - but the code handle this for Redeems/Refunds exists (see code around ConfirmTransaction in https://github.com/decred/dcrdex/pull/3082/files) ... and that probably means we need
to have similar functionality for Swaps
it's a bit unfortunate that for EVM-based transactions to bump fees "manual user action" is required (while for BTC or DCR it's handled automatically), perhaps it would be best to automate this for EVM-based assets as well ("manual user action" would need to be disabled for every transaction type except for Sends I guess to prevent interference with automated fee-bump functionality) - this is especially desirable for Swap transactions where user simply might not have enough time to react if he doesn't monitor all his open trades 24/7
The text was updated successfully, but these errors were encountered:
It is possible for Swap transaction to get stuck for 8+ hours (and/or never get mined),
I'm not sure what happens in case such Swap transaction does get mined eventually - I'm assuming Bison wallet will realize it needs to refund it ASAP and will send a Refund transaction (for Maker that's safe behavior, for Taker that's safe until 20h into the Match),
but what happens in case such Swap transaction never gets mined is - corresponding Match ends up in a hanging state where "it thinks Swap happened" (even thought it actually didn't) and "it thinks Refund is coming" (even though Bison wallet cannot possibly refund it since there is nothing to refund); all the while wallet also thinks Swap transaction is pending in mempool (which is technically correct but might be confusing to a User, so it's probably best to clean it up after Match state is resolved one way or another), here is how such stuck Match looks like:
I think there are at least two different ways this can be addressed:
Another note, #3131 also probably depends on the resolution of this issue since
Swapping
balance (underLocked
section) keeps showing funds reserved by stuck Swap transaction even after I've sent another Polygon transaction with the same nonce that got mined (effectively replacing/invalidating that Swap transaction completely) - which is probably due to corresponding Match still expecting Refund that will never happen.Another aspect of this issue - it seems bumping fee for Swap transaction for EVM-based assets (through manual user-action request) isn't working correctly because if Swap
tx1
was replaced bytx2
(with higher fee) Match won't know about it and we keep trying to convince servertx1
is the Swap transaction to look for (we do refund Swaptx2
successfully in that case though, that's good 👍 )it seems Redeems/Refunds would suffer from exactly the same issue of Match being unaware of fee-bumped transaction - but the code handle this for Redeems/Refunds exists (see code around
ConfirmTransaction
in https://github.com/decred/dcrdex/pull/3082/files) ... and that probably means we needThe text was updated successfully, but these errors were encountered: