-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Reorgs cause "old forked blocks" (below the reorg junction block) to be inserted/processed #1847
Comments
Before FastFinality is enabled, the fork choice is based on the TD(TotalDifficulty). I think, we can add the Finality check here, i.e. if the LastFinalizedBlock is 31,030,257, we can stop import blocks before it. |
Our Firehose tracer traces side chains and this was causing errors later downstream because our invariant is that forked blocks (side blocks) will never be emitted/imported if the fork height <= final block height. We implemented a similar fix as yours in our Thank you @brilliant-lx! |
System information
Geth version:
v1.2.10
with firehose instrumentation on top of itOS & Version: Linux
Commit hash :
github.com/streamingfast/go-ethereum
7535e671a0303f3c327f065d69da1ca558849420
Expected behaviour
Reorgs from block X to another version of block X should not import blocks X-2, X-1, etc. from a bad reorg.
This is causing issues with our instrumentation, but we see this mostly as an odd behavior and are trying to get to the bottom of this.
Actual behaviour
We saw the following logs when block
260
caused a reorg (drop=1, add=1). See the disordered block numbers. I have anotated the logs withX
next to the surprising block numbers, and appendedGOOD
orBAD
to see which blocks are now actually canonical.When block 31,030,260 came out, the LastFinalizedBlock was 31,030,257.
Then, processing a wrong version of block
31,030,255
makes no sense to me.Steps to reproduce the behaviour
The text was updated successfully, but these errors were encountered: