Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Swaps stuck as pending #775

Open
lukechilds opened this issue Apr 25, 2018 · 11 comments
Open

Swaps stuck as pending #775

lukechilds opened this issue Apr 25, 2018 · 11 comments

Comments

@lukechilds
Copy link
Contributor

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 #745 (comment)

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
Copy link
Contributor Author

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

@jl777
Copy link
Owner

jl777 commented Apr 25, 2018

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
Copy link
Contributor Author

lukechilds commented Apr 25, 2018

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
Copy link
Owner

jl777 commented Apr 25, 2018

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
Copy link
Contributor Author

@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
Copy link
Owner

jl777 commented Jun 15, 2018

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
Copy link
Owner

jl777 commented Jun 15, 2018

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
Copy link
Owner

jl777 commented Jun 15, 2018

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Owner

jl777 commented Jun 15, 2018

correct

DeckerSU pushed a commit to DeckerSU/SuperNET that referenced this issue Nov 5, 2022
* Add the ability for the Maker to try to spend TakerPayment again on recover_funds

* Add the conflicting transaction handling after listsinceblock is called

* Add test_find_output_spend_skips_conflicting_transactions green test

* Fix rustfmt warnings
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants