Swaps stuck as pending

[lukechilds]

Swaps stuck as pending

[lukechilds]

Can provide the entire history of socket messages for all three swaps if it's helpful.

[jl777]

a connect message puts you waiting for a connected. I think after 2 minutes and no "connected" message, you need to call a cancelorder with uuid. I will need to add special code to purge the threads for that uuid.

[lukechilds]

Is it possible for mm to do this automatically?

e.g if a connect message is received and after 2 mins there's no connected message, the trade is auto cancelled and a failed message is sent over the socket.

That way if you ever change the way this works or change the timeframe in the future, all client applications will still work properly.

[jl777]

I pushed a version that increases the power of cancel, so that any pending trade negotiation will be cancelled.

If the swap actually starts, then really, it shouldnt be cancelled but needs to follow the atomic swap protocol.

You can use whatever logic in the GUI to decide to issue the cancel uuid, and once you do if it was before the swap started, it should do a clean stop of any pending trade negotiation, regardless of whatever internal rules the mm has

[lukechilds]

@jl777 This is still causing a lot of issues. Especially on swaps that were pending and then the app was closed. When we restart we can't cancel(uuid) them because mm doesn't seem to be aware of them anymore.

What is the absolute maximum time a swap can be pending? I can run a loop every so often that just forces the swaps to display as cancelled in the UI if they've been in the 'pending' state for over a certain amount of time.

[jl777]

well uuid is an artificial field that was added per your request, but it isnt really used internally much. so on restart the uuid info is not in RAM anymore.

on a restart the requestid/quoteid is needed and it isnt really something you can do to just cancel it as the protocol requires to complete the required steps.

the time it can be pending depends on how far the swap has started. if it wasnt ordermatched, then 5 minutes is the longest. By existing the mm, it effectively does the most possible cancelling of pending swaps. so that is essentially a cancel all mechanism, keeping in mind that just because its cancelled doesnt mean it wont do any more tx. it will need to unwind in most cases and the tx needed depends on when it was stopped

[jl777]

https://bitcointalk.org/index.php?topic=1364951.msg13948905#msg13948905

that post gives an idea of what you are asking to be done. It seems you want to just stop the protocol midstream, which isnt exactly possible

[jl777]

basically on exit, all pending swaps have been "cancelled" as they wont advance any more than they can as constrained by the atomic swap protocol

[lukechilds]

To clarify, I'm not talking about cancelling, I'm talking about the "stuck pending swaps" issue that lots of users are reporting. These swaps never match, but we never get an error message for them. So they are stuck in the UI state forever as pending. I need to find a way to detect these.

It appears to be a bug in mm when a swap get's some communication from a peer (like a reserved message) but never matches. In this scenario an error message is never sent.

So either the bug needs to be fixed in mm so we get the correct error messages, or I need to force these swaps to display as failed if they've been pending for over a certain amount of time.

[lukechilds]

if it wasnt ordermatched, then 5 minutes is the longest

So there's no possible way for a trade to be matched 5 minutes after it was placed if we haven't got a connected message yet?

[jl777]

correct