fix(consensus/XDPoS): stabilize VerifyHeaders across v1-v2 switch, fix #2138 XFN-12#2139
fix(consensus/XDPoS): stabilize VerifyHeaders across v1-v2 switch, fix #2138 XFN-12#2139gzliudan wants to merge 1 commit intoXinFinOrg:dev-upgradefrom
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR fixes a result-ordering bug in XDPoS.VerifyHeaders where splitting headers into v1/v2 buckets and running two concurrent goroutines caused nondeterministic result-to-header mapping around the v1→v2 switch boundary. This led to misleading "BAD BLOCK" log messages (e.g., a v1-style error attributed to a v2-height header) and sync failures (issue #2138).
Changes:
consensus/XDPoS/XDPoS.go: Replaced the two-bucket/two-goroutineVerifyHeadersimplementation with a single goroutine that iterates headers in input order, dispatching each to the appropriate engine version.consensus/tests/engine_v2_tests/adaptor_test.go: AddedTestAdaptorVerifyHeadersKeepsInputOrderAcrossConsensusSwitchto assert that results arrive in the same order as the input slice across the consensus switch.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
consensus/XDPoS/XDPoS.go |
Rewrites VerifyHeaders to a single sequential goroutine preserving input order |
consensus/tests/engine_v2_tests/adaptor_test.go |
New regression test for result ordering across the v1/v2 switch |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
16837f0 to
41a76ec
Compare
41a76ec to
5e4ff8a
Compare
5e4ff8a to
8bb288c
Compare
8bb288c to
b04895c
Compare
a14f15c to
eea3308
Compare
…XinFinOrg#2138 XFN-12 Problem - Mixed v1/v2 batches around the switch boundary could produce non-deterministic verification behavior. - The adaptor previously relied on version-bucket concurrency and did not expose in-batch headers for GetHeaderByNumber lookups. - In practice this could surface as intermittent sync failures and misleading BAD BLOCK attribution near the switch height. Root cause - Verify result ordering and read visibility assumptions were too weak for mixed-boundary batches. - Engine helpers may query headers by number during verification, but batch context only shadowed hash-based lookups. Fix - Keep VerifyHeaders emission strictly aligned with input order. - Introduce verifyChainReader and shadow both hash and number lookups with in-batch headers: - GetHeader(hash, number) - GetHeaderByHash(hash) - GetHeaderByNumber(number) - This preserves deterministic per-header verification and avoids stale canonical reads during boundary processing. Tests - Add TestAdaptorVerifyHeadersKeepsInputOrderAcrossConsensusSwitch. - Add TestVerifyChainReaderReturnsBatchHeaderByNumber. Validation - go test ./consensus/XDPoS/...
eea3308 to
ec982d4
Compare
Proposed changes
fix:
VerifyHeadersProblem
Root cause
Fix
Tests
Types of changes
What types of changes does your code introduce to XDC network?
Put an
✅in the boxes that applyImpacted Components
Which parts of the codebase does this PR touch?
Put an
✅in the boxes that applyChecklist
Put an
✅in the boxes once you have confirmed below actions (or provide reasons on not doing so) that