ignore validation failed error for the genesis block #1499
Conversation
|
Warning Rate Limit Exceeded@Manav-Aggarwal has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 18 minutes and 48 seconds before requesting another review. How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. WalkthroughThe recent updates have streamlined error handling in the synchronization services for blocks and headers. A new Changes
Assessment against linked issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
Files selected for processing (2)
- block/block_sync.go (2 hunks)
- block/header_sync.go (2 hunks)
Additional comments: 1
block/header_sync.go (1)
- 113-125: > 📝 NOTE
This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [102-122]
The implementation of the
isGenesischeck and the conditional error handling in theWriteToHeaderStoreAndBroadcastmethod is consistent with the PR's objectives and the changes made in theblock_sync.gofile. The logic is sound and the approach to handle the genesis header is appropriate given the context.
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #1499 +/- ##
==========================================
- Coverage 50.36% 50.20% -0.17%
==========================================
Files 52 52
Lines 6731 6743 +12
==========================================
- Hits 3390 3385 -5
- Misses 3000 3016 +16
- Partials 341 342 +1 ☔ View full report in Codecov by Sentry. |
gupadhyaya
force-pushed
the
fix_validation_failure
branch
from
583b889
to
6e83cf4
Compare
|
Is there a regression test we can write for this? |
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (2)
- block/block_sync.go (2 hunks)
- block/header_sync.go (2 hunks)
Files skipped from review as they are similar to previous changes (2)
- block/block_sync.go
- block/header_sync.go
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (2)
- block/block_sync.go (2 hunks)
- block/header_sync.go (2 hunks)
Files skipped from review as they are similar to previous changes (2)
- block/block_sync.go
- block/header_sync.go
tightened the error skip logic to skip only ValidationFailed. this is the best we can do given that exact reason for validation failure ( i did not want to add additional efforts into this as we are tackling #1501 in v1 and it should totally remove this error skipping logic. let me know if this works. |
Manav-Aggarwal
force-pushed
the
fix_validation_failure
branch
from
7f01ffa
to
ba691bb
Compare
Fixes #969
This PR fixes the
validation failederror that is thrown by header and block sync, which happens when the sequencer callsBroadcastwhich also does publish the header/block locally for updating the store. This happens because the sequencer before broadcasting, for the genesis header, already does the store initialization and double store update causes this error. The prior initialization is required to start the syncer and there is no easier way to skip one of the two initializations. In future, can refactor the code to move syncer start to its own thread. But for now, ignoring the error is easier solution without adding any safety concerns.Summary by CodeRabbit