-
Notifications
You must be signed in to change notification settings - Fork 311
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
RPC sync failure #859
Comments
I don't this is a BDK specific bug. I had multiple users report the same issue when running LDK Node / LDK transaction-sync crate tests, which both rely on |
Yeah, it seemed like that to me too. Any specific thing that makes it go away for LDK? For me in BDK just ignoring the error and carrying on with sync worked.. |
Seems this might be connected to apoelstra/rust-jsonrpc#67, which might be fixed with |
Resource temporarily unavailable
failure in RPC[2023-02-10T06:50:19Z ERROR bdk_cli] Rpc(JsonRpc(Transport(SocketError(Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }))))
It's been known for some time that our rpc sync produces intermittent failures with the above error. This has been reported across many instances. But it doesn't caught in our CI. I have also struggled before to replicate this. Sometimes happens locally while running many test instances parallel. But it doesn't happen while running the sync manually. This made it very hard to debug.
First observed while upgrading
electrsd
's bitcoind version to0.23
: #613 (comment)Reported for mac by @notmandatory here : #749
Reported by @evanlinjin here : #650 (comment)
And as @afilini suggested, it's an internal TCP error, either by hitting bitcoin core's parallel request limits, or something even lower at os level.
Recently this has been reported to be happening consistently in
signet
, and I have been able to reproduce it enough to be able to debug successfully.To Reproduce
Sync any bdk wallet, from a fresh database, in
signet/testnet
network using the RPC blcokchain.Below is a
sync
output withbdk-cli
indebug
mode. And the sync ends with the above error.Which now clearly says that it's the
importdescriptors
call that fails.The corresponding
bitcoind
log (rpc
+http
):This shows that the descriptors are being imported successfully, and even rescanning of the wallet has started. This rescan takes 39 secs to complete. And during this period only the call fails in bdk.
Observations
This only happens for fresh sync only. Syncing the DB with electrum and switching back to RPC doesn't cause this error. This is probably because the rescan period is very small for a pre-synced wallet, as bdk will only tell core to rescan from last synced height.
Rescanning a synced db, again with rpc in signet now produces a successful sync.
This time rescan took 6 ms and it didn't throw the error.
Good News,
This was a tricky bug to catch, and even after identifying the call, I still don't exactly know what's causing the failure. But luckily, it's not a hard one to solve because the sync doesn't get affected by the error at all. The log above suggests that core carries on rescanning the wallet after importing all the keys, and just throws this os error in reply of
importdescriptors
(only iff the rescaning happens from genesis). We just happen to locally freak out by this os error and stop our sync.Instead, we could just safely ignore this error and continue our sync process. I have tested this locally, and it works (patch incoming soon). No data loss happens as the failing call is a non-data type.
Proposed Fix
We could also be hitting some core's internal parallel HTTP request limits. As the only time this happens is with the sequence of
,
Import a large number of descriptors
followed by aRescan from genesis
. Maybe this can be potentially solved by fixing #841So, for now the simplest thing to do is to just ignore this particular error for this particular call, and carry on the sync. And hopefully, with future improvements, this will go away. 😅
The text was updated successfully, but these errors were encountered: