fix(swaps): retry refund of maker swap v1 payment until successful#2132
fix(swaps): retry refund of maker swap v1 payment until successful#2132
Conversation
|
there are swaps that show this error on wonder what will happen to those? will mm2 retry those indefinitely? this is the swap json from this swap on maker: reason is that the to-be-refunded makerpayment never made it on to the blockchain, this tx does not exist on the explorer https://dogechain.info/chain/Dogecoin or does mm2 not retry this kind of failed swaps? |
Yep, mm2 will retry those indefinitely, thanks for noticing this. We can't skip the refund stage in case the transaction is actually on chain but the wait for confirmation took too long (problems in block production for certain chains), I think I should add a step to check if the transaction is on chain before retrying to refund forever, this should solve most problems. |
The tx from the swap i posted didn't even made it to the chain. The maker payment tx does not exist on chain. mm2 still tried to refund it later. |
I understand, but this error https://github.com/KomodoPlatform/komodo-defi-framework/blob/df6ab98b3b2ee84918bfc0bf1bc03d1e1f219985/mm2src/coins/utxo/rpc_clients.rs#L197-L205 should have been returned from wait for confirmation instead of the error returned here {
"error" : "maker_swap:922] !wait for maker payment confirmations: rpc_clients:158] Waited too long until 1708809594 for transaction 96c3e5dd0e446d2ef59b89957ae7d0e9fc2e14d479a23b85ce73e0664daf2e5e to be confirmed 2 times"
}Which makes me think that this transaction made it but was deleted from the mempool due some reason or confirmed then got deleted due to a chain reorganization, that's why we have to try to refund transactions either way and never assume that it never made it. |
I think this error was returned just due to how |
@cipig said the transaction never made it to the chain and couldn't be refunded. |
yes, makerpayment can't be found on explorer... could be that it initially made it to mempool, but was never mined and got removed later (DOGE has problems with mempool anyway because it's getting spammed by thousands of transactions) |
It will not retry it since I will add a step to check if the transaction is on chain before starting the retry loop. |
… for all coins and then checked before retrying refunds
perfect here is another failed swap that could stay in the loop forever: i mentioned the problem here: #1567 |
|
Superseded by #2280
This can be an irrecoverable error as it makes no sense for the user to try to get the funds when they will pay more fees than what they will get. But the problem is for some chains such as BTC, there can be fee spikes and they can get the funds later. We will need to think of a solution. |
The specific problem happens on any chain when you swap a too low volume. The solution is to set min_volume of orders tp 10x txfee instead of 10x dust, like it is now. |
Makes sense, but what about chains with dynamic fees? |
There aren't that many left and we could try to switch those to fixed fee too, that is better anyway if you eg want to swap all your balance. The only one left where it also makes sense is BTC, but which has a min_volume set to 0.00777 anyway, so not affected by the problem. There is also DOGE though, which we switched backed from fixed to dynamic because of network congestion from an attack. Anyway, is the txfee not queried anyway when you post an order? If so, then it can be used to determine min_volume. |
Related to #1941, #1703
More description will be added