-
-
Notifications
You must be signed in to change notification settings - Fork 414
fix: don't log proposer boost reorg logs during sync #8363
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
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## unstable #8363 +/- ##
=========================================
Coverage 54.09% 54.09%
=========================================
Files 850 850
Lines 64193 64194 +1
Branches 4855 4853 -2
=========================================
+ Hits 34723 34725 +2
+ Misses 29393 29392 -1
Partials 77 77 🚀 New features to boost your workflow:
|
Performance Report🚀🚀 Significant benchmark improvement detected
Full benchmark results
|
|
/gemini review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces several improvements to the proposer boost reorg logic. The changes correctly restrict the reorg checks to blocks with a slot greater than or equal to the current slot, which prevents irrelevant logs during sync. By removing the isGossipBlock flag, the logic is now correctly applied to blocks from all sources, including API and req/resp, which enhances correctness. The refactoring to use a single currentSlot variable throughout the importBlock function is a good improvement for consistency and robustness. Overall, the changes are well-implemented and improve the quality of the codebase.
ensi321
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
|
🎉 This PR is included in v1.35.0 🎉 |
Motivation
We currently print proposer boost reorg related logs
Strong block detected ...during sync but it's not relevant there asshouldOverrideForkChoiceUpdatewill never return true ifblock.slot < currentSlot.There is also an edge we currently don't handle since we only run proposer reorg checks if block is received through gossip but in theory (although unlikely in practice) we can also receive the block via req/resp (close to 0% on mainnet).
Description
block.slot >= currentSlotisGossipBlockflag to also check if receive block via req/resp, this also means we run the checks if receive block from api meaning we a previous proposer, we could additional check if we are previous proposer cache if we wanna handle that case explicitly