refactor: drop circular dependency over validation <-> masternode/payment#7339
refactor: drop circular dependency over validation <-> masternode/payment#7339knst wants to merge 6 commits into
Conversation
|
|
✅ Review complete (commit dc2e5ea) |
WalkthroughThis PR introduces a Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/validation.cpp (1)
2571-2581:⚠️ Potential issue | 🟠 Major | ⚡ Quick winPass this chainstate’s chain into payment validation.
ConnectBlock()runs on whicheverCChainStateis being advanced, but these calls still threadm_chainman.ActiveChain().IsBlockValueValid()uses that chain forCSuperblock::GetPaymentsLimit(...), andIsBlockPayeeValid()uses it for superblock/governance checks, so background/snapshot validation can evaluate a block against the wrong chain context. Passm_chain(or a local reference to this chainstate’s chain) instead.Suggested fix
+ const CChain& chain = m_chain; - if (!m_chain_helper->mn_payments->IsBlockValueValid(m_chainman.ActiveChain(), block, pindex->nHeight, blockSubsidy + feeReward, strError, check_superblock)) { + if (!m_chain_helper->mn_payments->IsBlockValueValid(chain, block, pindex->nHeight, blockSubsidy + feeReward, strError, check_superblock)) { // NOTE: Do not punish, the node might be missing governance data LogPrintf("ERROR: ConnectBlock(DASH): %s\n", strError); return state.Invalid(BlockValidationResult::BLOCK_RESULT_UNSET, "bad-cb-amount"); } @@ - if (!m_chain_helper->mn_payments->IsBlockPayeeValid(m_chainman.ActiveChain(), *block.vtx[0], pindex->pprev, blockSubsidy, feeReward, mn_reward_era, check_superblock)) { + if (!m_chain_helper->mn_payments->IsBlockPayeeValid(chain, *block.vtx[0], pindex->pprev, blockSubsidy, feeReward, mn_reward_era, check_superblock)) { // NOTE: Do not punish, the node might be missing governance data LogPrintf("ERROR: ConnectBlock(DASH): couldn't find masternode or superblock payments\n"); return state.Invalid(BlockValidationResult::BLOCK_RESULT_UNSET, "bad-cb-payee"); }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/validation.cpp` around lines 2571 - 2581, ConnectBlock is calling m_chain_helper->mn_payments->IsBlockValueValid(...) and IsBlockPayeeValid(...) with m_chainman.ActiveChain(), which can be the wrong chain during background/snapshot validation; change those calls to pass this CChainState's chain (use m_chain or a local reference to m_chain) instead of m_chainman.ActiveChain() so CSuperblock::GetPaymentsLimit and superblock/governance checks use the correct chain context (update the two call sites that reference IsBlockValueValid and IsBlockPayeeValid to pass m_chain).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@src/validation.cpp`:
- Around line 2571-2581: ConnectBlock is calling
m_chain_helper->mn_payments->IsBlockValueValid(...) and IsBlockPayeeValid(...)
with m_chainman.ActiveChain(), which can be the wrong chain during
background/snapshot validation; change those calls to pass this CChainState's
chain (use m_chain or a local reference to m_chain) instead of
m_chainman.ActiveChain() so CSuperblock::GetPaymentsLimit and
superblock/governance checks use the correct chain context (update the two call
sites that reference IsBlockValueValid and IsBlockPayeeValid to pass m_chain).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: ec84e219-dc6e-4c80-954b-025e317994e1
📒 Files selected for processing (10)
src/evo/chainhelper.cppsrc/evo/creditpool.cppsrc/masternode/payments.cppsrc/masternode/payments.hsrc/node/miner.cppsrc/rpc/masternode.cppsrc/test/block_reward_reallocation_tests.cppsrc/validation.cppsrc/validation.htest/lint/lint-circular-dependencies.py
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
Clean refactor PR that decouples CMNPaymentsProcessor from ChainstateManager and replaces a boolean fV20Active flag with an MnRewardEra enum computed by callers via a new GetMnRewardEraAfter helper. Both verifier agents converged on no blocking findings, and the two nitpicks raised were low-signal observations dropped during verification.
|
This pull request has conflicts, please rebase. |
… helpers It helps to minimize dependencies of masternode/payments on validation.h and move calls such as is-deployment-active outside to callers
dc2e5ea to
37ad935
Compare
|
This pull request has conflicts, please rebase. |
converted to draft as it conflicts with 7314 and 7330
Issue being fixed or feature implemented
There's an exception for existing circular dependency in test/lint/lint-circular-dependencies.py:
"masternode/payments -> validation -> masternode/payments",What was done?
MnRewardErato use in masternode/payment helpersHow Has This Been Tested?
Run unit & functional tests; run linter
test/lint/lint-circular-dependencies.pyPlease note, that 2 other circular dependencies always had existed but had been hidden behind
masternode/payment <-> validation:Breaking Changes
N/A
Checklist: