Fix: getblockfrompeer was always requesting block from the first peer #8069
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I noticed my core-lightning instance was completely stuck on a block in this issue.
Manually running
getblockfrompeer
on a peer having the block on which core lightning was stuck allowed it to carry on.I suspect it is because you were always fetching the block from the first peer rather from the last in the list.
Tested this PR for myself, and it fixed the issue.
Additional notes: You seem to request a block even if the node doesn't have a
"servicesnames"
set toNETWORK
, so it is quite slow... if for example the 10 first peers I am connected to are pruned, for every block, it asks to all of them.Log before this PR: (note that the log is misleading, when it says
from peer 4496, skip
is was really just asking to the same peer all the time)Log after this PR: