fix(electrum): fixed chain sync issue#1145
fix(electrum): fixed chain sync issue#1145danielabrozzoni merged 1 commit intobitcoindevkit:masterfrom
Conversation
07d282f to
330dfc5
Compare
|
I've added a debug print: diff --git a/crates/electrum/src/electrum_ext.rs b/crates/electrum/src/electrum_ext.rs
index 1ce16627..759732da 100644
--- a/crates/electrum/src/electrum_ext.rs
+++ b/crates/electrum/src/electrum_ext.rs
@@ -313,6 +313,7 @@ fn construct_update_tip(
.map(|h| h.block_hash());
(start_height..).zip(hashes).collect::<BTreeMap<u32, _>>()
};
+ println!("Found blocks: {:?}", new_blocks);
// Find the "point of agreement" (if any).
let agreement_cp = {I then sent some signet coins to my address, the txid of the transaction is |
|
With this patch applied, what I saw is that after the transaction is confirmed in the block on signet, I sometimes would have to sync 2-3 times for the balance to show 0 unconfirmed sats. Before the patch, what I saw was that the local chain tip was always a block behind, so the balance would always show unconfirmed sats until after the second confirmation (again, sometimes requiring running sync 2-3 times). Console output after 1 confirmation: |
|
I can try again later, I just wanted to say, I'm not opposed to merging the PR, I just want to make sure that it actually fixes the issue before closing it. I tried syncing multiple times and while the tx had only one confirmation it would still show up as unconfirmed. |
|
Hmm. Maybe @evanlinjin can see if this fixes the bug in his environment? |
|
If I'm wrong, and after merging this PR nobody is able to reproduce the bug again, we can just close the issue and calling it a day; but I'd like to be sure before closing. I've reproduced the bug again:
|
|
WRT to whether there's still an issue. Can we write a test against |
|
See also earlier PR from @vladimirfomene to add tests: https://github.com/bitcoindevkit/bdk/pull/979/files |
|
Replaced by #1163. We will close this PR when that one is merged |
I've closed #1163 as I agree with @LLFourn's points and we can update the bug fixes to electrum crate separately. @LagginTimes I think the next steps should be
|
|
Since I'm the only one being able to reproduce the bug still, do you need help with debugging? :) |
330dfc5 to
d58f13d
Compare
|
Rebased with #1182 CI fixes. |
Fixed a logic error in `construct_update_tip` in `electrum_ext.rs` that caused the local chain tip to always be a block behind the newest confirmed block.
d58f13d to
1010efd
Compare
A chain sync test was written as part of #1171 that successfully reproduced the issue described in #1125. This PR seems to at least partially fix #1125 w.r.t. patching a logical flaw that was confirmed with the #1171 test. However, I am uncertain if it fixes @danielabrozzoni's issue that both @evanlinjin and I have unfortunately been unable to reproduce. |
Description
This may or may not fix #1125.
Fixed what appeared to be a logic error in
construct_update_tipinelectrum_ext.rsthat caused the local chain tip to always be a block behind the newest confirmed block.Checklists
All Submissions:
cargo fmtandcargo clippybefore committingBugfixes: