swapstatus(requestid, quoteid) shows invalid swap data on fresh swaps
#631
Comments
|
maybe you can wait 3 seconds before the first query? you are actually querying it and it is returning all the data it has about the swap what is happening is that the requestid/quoteid is added to the list of all swaps it seems for the first few seconds there is no new file as I am now adding the requestid/quoteid to the tracking BEFORE it actually starts (to fix the limbo issue). Of course I still need to fully fix the limbo issue, so maybe this is a side effect of that bug. However, internally what is happening is that there is no info about that swap at all the first couple seconds after it appears on the tracking list. so "swap never started" is technically accurate and I have no way of knowing if it will start in 2.1 seconds or maybe it wont ever start... this uncertainity is the result of needing the other party to be following the protocol and if they dont, it eventually times out. So we can say that if after 2 minutes it is still in the "swap never started" that it wont ever start. |
|
Maybe it would be more accurate to keep the swap in the It seems like we need more statuses, it's kind of confusing because However when we query So it seems like two different commands have two different ideas of what Could I propose some more statuses to give us a better idea of what's happening? A trade should always have one of the following statuses:
The only possibilities should be:
We can use
Preferably also combined with a helpful error message e.g: "Unable to match", "Other party cancelled" etc. |
|
I will try to do this, but cant guarantee there wont be some edge cases, especially if you are finding gaps of one second. |
* Exclude mm2-seednodes-optimisation from CI triggers. * Count the number of sent messages and their total size in seednode loop. * Add max_msg_size to seednode_loop metrics. * Log send buffer size when electrum client is connected. * Log send buffer size for seednode listener and every connected client TcpStream. * Log nodelay value of TcpListener and every TcpStream. * Try to set nodelay = true. * Try to set_send_buffer_size to 200000. * Try to refactor seednode_loop to async_std. * Recv messages only and log them. * Drop connection if EOF reached. * Enable rebroadcast back. * Log message send attempts. * Try to increase channel capacity. * Use vec of mpsc senders instead of async_std mpmc. * Remove excessive logging. * Log the invalid JSON message and it's sender. * Skip lines that are not valid JSON. * Log JSON deserialize error only when buffer.len() > 1. * Try tokio TCP implementation instead of async_std. * Log the case when buffer can be probably lost. * Split incoming connections TcpStreams and process them in separate async loops. * Do not send message back to peer from which it was received. * Remove excessive logging. * Enable CI build for this branch back. * Try to spawn read and write processing loops on tokio 0.2 runtime. * Use String as P2PMessage content to avoid non-deterministic serialization issues. The deserialized and then serialized message might produce non-equal string so same message can be serialized to JSON differently causing double processing on client nodes connected to several seeds. * Explicitly disable debug_assertions for release profile. * Update tokio to 0.2.22. * Fix after merge.
Following on from #626
Once a swap moves from
pendingtoswapsinrecentswapsand gives usrequestid/quoteid, if we try to query it it shows invalid data:As soon as the swap is moved out of pending and we can query it it's in a weird state for 2.1 seconds. There is an error saying it never started but the status is set to
finishedwhich is confusing. After 2.1 seconds it starts it's normalpendingstatus.I think the correct behaviour should be that as soon the trade has moved from
pendingtoswapsin theswapstatusoutput so we can query it, it should be set aspending.The text was updated successfully, but these errors were encountered: