-
Notifications
You must be signed in to change notification settings - Fork 54
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
Transactions being returned out of order #75
Comments
I don't think this was a known issue, and I'm guessing this may be related to the specific server your are running because I've never seen this happen with electrs. Looking at the code it's also very weird that this is happening: we do have code to re-order the replies from the server for batch requests: rust-electrum-client/src/raw_client.rs Lines 706 to 723 in ca48628
Either there's an issue there, or the server is replying with the wrong request id. Can you try running your tests with |
That's what I'm starting to think, but here's the trace. I replaced the electrum server but let me know if I should include that. https://gist.github.com/0xarvin/9baee245a45e6e409d9be65e4a447101 |
Which electrum server software are you using where you see this issue? |
@notmandatory We spun up a set of signet nodes: url: ssl://electrum.nodes.wallet.build:51002 |
+1 for this issue. Happens for many servers, not just one special guy. Most servers I tested exhibit this bug. Including:
I can confirm the cause does NOT originate within this library. The culprit electrum servers are not respecting JSON-RPC request IDs correctly. If i ask for a series of transactions with a given set of request IDs, the server will return responses for those request IDs but the actual response data might not be mapped to the correct response IDs. E.g. request with ID I imagine this is a bug somewhere in the upstream servers' async request handling code. We could easily fix this inside this library by sorting the response TXs by their true TXID. However, if the servers aren't respecting JSON-RPC request IDs, it's hard to know what other properties of JSON-RPC they might be breaking. I didn't test any other batch methods to see if they suffered from the same problem as The fact that so many servers are apparently broken in this respect is concerning and suggests that maybe a client-side hack is needed, otherwise callers will inevitably reopen issues like this in the future. |
I can confirm that this problem is not limited to batched transaction fetching. It also affects |
Via BDK, we're pulling transactions for a Wallet through a signet electrum instance. Recently, we've noticed that the order that we call batch_transaction_get_raw isn't being respected by electrum and results in the transactions being returned by the client to also be out of order as the reader takes the top result if it's unable to grab a hold of the lock on the reader
This doesn't affect production calls in BDK but only in tests as there's a debug assert here. Was wondering if there's anything that I'm missing or if this is a known issue.
Wallet Descriptor for example:
wsh(sortedmulti(2,[e5cd860e/84'/1'/0']tpubDFVZtuMvX7n6DCWbNAgq361KiJdVFBy4D1sZmdafF1zDNW6dv79MwbK6JBRxGV42BS4STayPsG7Prn3QT7LQwzfaBhE8YhgCs4VzhkYVWTg/0/*,[73ee041b/84'/1'/0']tpubDEPCQp4KHW3sS5o18QbknuC6dtQJPFgWtS6e8wm6ewnc2B1vucCnKf9uf9gCddHeJoK5d5hgJv5ji5Q8VnpT4h9ydsi9FE4t8F2GoPrFPYa/0/*,[08a73043/84'/1'/0']tpubDEZ565bfePfqSVkSfrLaR7g5nruLDWxJFKkJvKWUpMEQBsS9p2f5um5uTwgmKWuHbyoiythmEvDRSgdEoYBgLXfosBsjMBTp1jev9wfi2q9/0/*
Network:
Signet
The text was updated successfully, but these errors were encountered: