-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
"blockchain_tree: Block hash not found in block indices block_hash=0x743071" #3446
Comments
Can you share bigger logs (dump the file if you can) is this happening right after the pipeline finished its initial sync. And can you share logs after restart (both reth and lighthouse). Why i ask for additional logs is that this log ( But what I want to see is this "I can't sync any further" Is it stuck and can I see anything useful from logs. |
I dont save logs to disk (previous time ran out of space because the file go so big), and I just fucked up while copying tmux's output (somehow erased the whole thing). But here is what happened: what happened is Reth synced, then synced the 1300 or so blocks it missed while syncing, then synced the 130 blocks it missed while syncing the 1300 blocks, tried to insert block number 17576454 and at this point the "failed to canonicalize the head hash" error happened Do you want me to keep trying to run it for a while to see if it unfolds itself ? |
Even this info is great!
This could help, I would leave it and see is there are any changes. Another approach as you said you already restarted it, maybe we can try that and you can scrap the logs from the start. |
wanted to post log file but I have an old bug where nothing is ever written in /.cache/reth/logs/reth.log despite running RETH_LOG=info reth node --log.persistent.
|
this warning is expected if the node didn't receive the payload and therefore can't make the new FCU.head canonical |
If it's expected, is there something to do to fix it ? |
fixing what exactly? |
Ty for logs. That warning shouldn't be a warning, it is flow that can happen, it just means that we need to fetch the blocks that node does not have. @mattsse do we have any logs that tell us that we reverse download the block to fill the gap? |
debatable whether this should be a warning or info
I think not on info, but we should highlight this |
Here is what happens after I restart the node:
etc... until it reaches block 17577233 and loop trying to insert it. CL client logs:
|
there's currently an issue where reth is temporarily unresponsive while it inserts downloaded blocks, eventually, it should catch up and function normally. working on improving this here #3416 |
Describe the bug
My node finished syncing today's morning.
However, it kept giving me this warning:
I restarted my node and Lighthouse, and this time the node tried to insert block backwards (try_insert_validated_block) until it reached block number 17576413. At this point it only tried to insert this specific block.
My CL client spammed "Execution engine call failed" and "Failed to update execution head" messages.
I can't sync any further
Steps to reproduce
idk
Node logs
No response
Platform(s)
Linux (x86)
What version/commit are you on?
46d4795
What database version are you on?
1
If you've built Reth from source, provide the full command you used
RUSTFLAGS="-C target-cpu=native" cargo install --locked --path bin/reth --bin reth --profile maxperf --features jemalloc
Code of Conduct
The text was updated successfully, but these errors were encountered: