You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We log a REORG! if we see a chain reorg but we should always have a corresponding fork? in the logs as the reorg causes the chain head to migrate from one fork to another (and by definition we should have processed both blocks at the previous height.
I'm not entirely sure why this is happening and we should investigate further.
Not sure if this is a symptom of a larger issue or potentially just a logging issue.
The text was updated successfully, but these errors were encountered:
#2349 makes the assumption that if we requested a block then we are syncing and we should suppress the header broadcast when receiving the block.
This is not correct behavior though because we can also request full blocks when failing to hydrate compact blocks. And in this case we do want to broadcast the header to our peers.
We don't see the "fork?" log msg in some of these examples because we suppressed both the logging callback and the header broadcast due to us incorrectly assuming we were syncing.
We should suppress broadcast (and callbacks) iff -
we specifically requested this block and
we requested it due to missing blocks during sync
If we request a block due to a compact block not hydrating successfully then we want to broadcast the header to our peers.
Rather than tracking a true/false "did we request this block?" we need to track the opts (SYNC or NONE) related to the originating block request.
During sync we will track a requested block with opts=SYNC (suppressing the broadcast).
During block hydration we will track a requested block with opts=NONE (broadcasting normally).
We log a
REORG!
if we see a chain reorg but we should always have a correspondingfork?
in the logs as the reorg causes the chain head to migrate from one fork to another (and by definition we should have processed both blocks at the previous height.I'm not entirely sure why this is happening and we should investigate further.
Not sure if this is a symptom of a larger issue or potentially just a logging issue.
The text was updated successfully, but these errors were encountered: