Conversation
…ByEpoch The endpoint walks from epochBlockNum-1 down to the previous epoch switch block, but the v1 engine counts the genesis block as the epoch switch that opens epoch 0. Calling the RPC with block number 0 therefore passed the epoch-switch guard and then underflowed the unsigned number: the walk asked for the header at 2^64-1 and the endpoint failed with "failed to get header at number 18446744073709551615 hash 0x0000...", naming a block that cannot exist instead of the reason. No epoch precedes genesis, so there is no signing to count there. Answer with an empty count, and say so in the doc comment. Introduced together with the endpoint (XinFinOrg#2223); no upstream counterpart to port, the RPC is XDPoS-specific.
|
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: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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.
🟢 Approval recommended
The focused guard prevents the underflow and is covered by an appropriate regression test.
Pull request overview
Fixes unsigned underflow when querying signing counts for the genesis epoch switch.
Changes:
- Returns an empty count for genesis.
- Documents genesis behavior.
- Adds regression coverage.
File summaries
| File | Description |
|---|---|
consensus/XDPoS/api.go |
Guards the backward walk at block 0. |
consensus/XDPoS/api_test.go |
Tests genesis epoch-switch behavior. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Problem
XDPoS_getSigningTxCountByEpochwalks fromepochBlockNum-1down to the previous epoch switch block. The v1 engine counts the genesis block as the epoch switch that opens epoch 0 (0 % Epoch == 0), so calling the RPC with block number0passes the epoch-switch guard and then underflows the unsigned subtraction inconsensus/XDPoS/api.go:The message names a block that cannot exist instead of naming the reason. Nothing crashes and no wrong data is returned, but the endpoint is unusable for the case: it is reachable with
XDPoS_getSigningTxCountByEpoch(0)(or"earliest") and answers with a number that can never be looked up.Fix
No epoch precedes genesis, so there is no range of blocks to walk and no signing to count there. Return an empty count, and state the case in the doc comment of the method.
Test
TestGetSigningTxCountByEpochGenesisasserts the precondition (the v1 engine reads genesis as an epoch switch, which is what makes the case reachable at all) and pins the empty answer for block 0. Without the fix it fails with the underflow message above.Note
This is a pre-existing defect of the endpoint, present since it was added in #2223; it is unrelated to the import-loop work in flight. There is no upstream counterpart to port - the RPC is XDPoS-specific.