fix: reject unsupported custom LLMQ sizes#7448
Conversation
The devnet `-llmqdevnetparams` and regtest `-llmqtestparams`, `-llmqtestinstantsendparams` and `-llmqtestplatformparams` overrides parsed a `<size>:<threshold>` pair and assigned the size to the LLMQ params without any upper bound. Sizes above 400 were therefore accepted at startup even though the signing protocol cannot carry them: signing session inventories and batched sig-share messages are bounded at 400 entries (MAX_MSGS_TOTAL_BATCHED_SIGS), and the bounded intake work extends that limit to the receive path. A node configured with, say, a 500-member quorum would build inventories its peers reject, so the quorum could never recover a signature - a confusing runtime failure far away from the misconfiguration. Introduce a single authoritative Consensus::MAX_LLMQ_SIZE (400) in the low-level llmq/params.h, which chainparams already includes, and define the existing message-specific MAX_MSGS_TOTAL_BATCHED_SIGS in terms of it so the two limits cannot drift apart. Chain-parameter construction now fails fast with a clear error when an override requests a size above the maximum. Sizes at or below 400, including the small custom values used by the functional test framework, are unaffected. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
✅ Review complete (commit a54fcbe) |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
WalkthroughAdds Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ 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 |
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
Source: codex (gpt-5.6-sol, reasoning=high) — general & dash-core-commit-history lanes; sonnet5 (claude-sonnet-5, effort=high) — general & dash-core-commit-history lanes; opus (claude-opus-4-8) — general & dash-core-commit-history lanes. Final verifier: claude-sonnet-5 (verifier-sonnet5-7448-1783873850). Orchestrator (openai/gpt-5.6-sol) is orchestration-only, not a reviewer or finding source. Independently verified PR #7448 at head a54fcbe (base develop): the diff introduces Consensus::MAX_LLMQ_SIZE(400), ties MAX_MSGS_TOTAL_BATCHED_SIGS to it, and adds the upper-bound rejection to all four override paths (-llmqdevnetparams, -llmqtestparams, -llmqtestinstantsendparams, -llmqtestplatformparams) exactly as described. New unit test correctly exercises the 400-boundary and 401-rejection for all four paths. Single clean non-merge commit; message matches diff. All six native-token lanes found no defects, and independent verification confirms no in-scope issues.
Note: GitHub does not allow me to approve my own PR, so this verified clean review is posted as a COMMENT.
Issue being fixed
Devnet and regtest LLMQ size overrides accepted quorum sizes above 400 even though the signing protocol cannot carry them. Signing-session inventories and batched signature-share messages are capped at 400, so an oversized custom quorum could start successfully but fail later when peers exchange signing shares.
What was done
Consensus::MAX_LLMQ_SIZEas the authoritative 400-member protocol maximum.MAX_MSGS_TOTAL_BATCHED_SIGSto that shared maximum so the limits cannot drift.-llmqdevnetparams,-llmqtestparams,-llmqtestinstantsendparams, and-llmqtestplatformparamsvalues during chain-parameter construction.This is a fail-fast configuration fix discovered while reviewing #7418. It does not change mainnet or testnet parameters, and accepted custom sizes at or below 400 retain their existing behavior.
Validation
feature_llmq_signing.py: both variants passed.git diff --checkship, no findings.Scope
This intentionally adds only the missing upper bound. Existing behavior for zero, negative, or otherwise inconsistent custom size/threshold pairs is unchanged.