-
Notifications
You must be signed in to change notification settings - Fork 222
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
Comments
Can provide the entire history of socket messages for all three swaps if it's helpful. |
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. |
Is it possible for mm to do this automatically? e.g if a That way if you ever change the way this works or change the timeframe in the future, all client applications will still work properly. |
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 |
@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 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. |
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 |
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 |
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 |
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 It appears to be a bug in mm when a swap get's some communication from a peer (like a 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. |
So there's no possible way for a trade to be matched 5 minutes after it was placed if we haven't got a |
correct |
* 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
Thanks for implementing the
failed
message on non-matched trades. It seems that if we getreserved
orconnect
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:Not sure if this is what you were referring to in #745 (comment)
Is this fixable?
The text was updated successfully, but these errors were encountered: