Consequtive sync is not working #94
Comments
|
It might help to look at the logs emitted by nakamoto. Does bitcoind send a |
|
I tried with It seems its getting all the |
|
Yeah indeed, so it has scanned up to and including block 197, but it can't proceed further because it's missing cfheaders 198-202. The question is why has it not received them and/or were they correctly requested. I'd suggest running with |
|
Looking at this code: nakamoto/p2p/src/protocol/cbfmgr.rs Lines 339 to 358 in 2158338 We only retry the cfheaders request if we're able to find another peer to retry. In this case, since we're only connected to one node, if that node never responds, we never retry. That could be the reason, although it would be strange for bitcoind to not respond in this situation, so it would be good to have more detailed logs with just |
|
You can try this #96 - if the issue is fixable by a retry, this should do it at least. |
|
I tried with #96 but it din't work. Same situation.. Here's the bitcoind debug log for the run https://pastebin.com/U1yN7teu. Its hard to tell from the log which headers were sent and which weren't. To me it seems bitcoind is responding to all getcfheaders and getcfliters requests as they arrived. So maybe nakamoto didn't asked for the last few headers? The problem is also occurring if the 2nd sync bunch is anything more than 1 block.. For 1 block sync it works.. |
|
Never experienced this running Nakamoto 🤔@rajarshimaitra can you share the current code so I can run locally |
rajarshimaitra
added a commit
to rajarshimaitra/bdk
that referenced
this issue
Oct 2, 2022
Includes various adhoc updates to tests and nakamoto module for WIP testing issue. This commit at stage of issue reported in : cloudhead/nakamoto#94
|
My code is the one I shared in the description #94 (comment) Where The test operations are
If you can reproduce this action in your own testing codes or however you used nakamoto before I would like to try them out too.. The above test code is included in the commit here https://github.com/bitcoindevkit/bdk/blob/d6d0320dd969cb644d0e5753b5b321fb6039ebe7/src/testutils/blockchain_tests.rs#L972-L988 Under this WIP PR in bdk bitcoindevkit/bdk#751 (checkout the PR tip) And it is playable with the command |
So I was able to run the test successfully using the commit here but it took an awful long time to find cfheaders. Still making my research, but that's my log if that's anyway helpful. |
|
Oh thats interesting.. Seems like it took last 4 mins to get the remaining 2 headers? But in my case its holding off even longer.. Will try to see if I can reach than finish in my local.. Thanks for the log.. |
|
Fixed here: #97 The reason others haven't experienced this bug is that it's not likely to be hit in production: it happens when blocks are received shortly one after the other, while the client thinks it's in sync, ie. an environment only really possible in regtest, or if two blocks were to be found in short succession on mainnet. The above passes the test on my machine. |
|
Thanks a lot @cloudhead .. I verified #97 fixes this.. Closing it on that note.. 🥳 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
Consequitve syncing of 100 blocks in regtest isn't working. When we create a sequence of blocks from height 0:102 and sync the client, it works as expected. Then create another new 100 blocks in regtest, height 102:202, and sync the client, the sync halts at an intermediate height.
Test Code
Extra logging
To debug internally I set an extra log
println!("Asking filters : {} : {}", range.start(), range.end());atnakamoto/p2p/src/protocol/cbfmgr.rs
Line 488 in 90cc3ea
Output
The sync is paused at this stage because the client asked till 199, while the tip at core node is at 202.
Observations
This ask height for Sync 2 is also sporadically changing on different runs. Same code with the next run is giving different number.
Now its halted after asking till height 200.
So for some reason the client is confused on whats the tip height till which it needs to ask filters for.
The text was updated successfully, but these errors were encountered: