jl777 / SuperNET

57 stars 222 forks source link

Swaps stuck as pending #775

Open lukechilds opened 6 years ago

lukechilds commented 6 years ago

Thanks for implementing the failed message on non-matched trades. It seems that if we get reserved or connect messages we never get a failed event, even if the trade never progresses from there.

Here some of the socket messages we've got form trades that never got a failed event:

[
    ["request", "reserved", "reserved", "connect", "connect"],
    ["request", "request", "reserved", "reserved", "connect", "reserved"],
    ["request", "reserved", "reserved", "connect", "connect"],
]

Not sure if this is what you were referring to in https://github.com/jl777/SuperNET/issues/745#issuecomment-382362055

updated with a special failed message -9999 but it might give spurious events if after other messages have come in. Not sure it will, but not sure it wont.

Is this fixable?

lukechilds commented 6 years ago

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

jl777 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

correct