eth/handler: more reliable announcements #22249
Closed
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.
This is based on to #22241, but could really be applied on
master
aswell. While working oneth66
, where I used one 'relayer' and one 'isolated' node which spoke only to the relayer, I noticed that block import did not happen one by one, but rather in batches whenever it got 'far enough' behind.After diving deep into it, I concluded that the problem was:
relayer
gets a block via broadcast, but the block is1 second
future fromNow
, the blockhash
as known atisolated
.relayer
does, he gets the same block a split second later, and it gets imported properly.isolated
, since he's already marked as having it.This all leads to
isolated
missing out on announcements.There are several ways to handle this, and I tried a few, end eventually settled on performing a small wait (up to 2 seconds) in the block fetcher, if it notices that a given block is indeed future, but the timestamp is
<=2s
from now. At that point, we're already executing in a goroutine, and sleeping + doing successfull import there prevents the hash from being sent to thedone
channel prematurely.Anyway, the whole point of this particular PR is the last commit. With that, my two goerli-on-eth66 nodes work fine with eachother, progressing in lock-step block by block
This PR also fixes what I think is an oversight during
queue
processing in the fetcher -- but maybe it was intentional and I have just overlooked some aspect.EDIT: The fix I made, eventually, is just a band-aid on a broken thing. I think a more correct fix would be to have two separate paths: broadcasts done as now, and announcements triggered/sent based on a subscription of imported blocks. That way, we would be guaranteed that regardless of how the block is imported (via fetcher or via
procFutureBlocks
), the block would be announced, and at the time of the announcement, the block is fully imported)