fix(rpc): derive active DKG count from membership

[PastaPastaPasta]

Issue being fixed or feature implemented

quorum dkginfo is meant to answer a simple question: is this masternode participating in a DKG right now, or can it be restarted safely? active_dkgs answers it wrongly at both ends of a session. At a DKG start block it stays zero until the asynchronous DKG worker publishes its local debug record, and afterwards it keeps counting expired debug records.

What was done?

active_dkgs is now computed from membership at the captured chain tip instead of debug-session tracking:

• Sessions the given or local masternode is a member of count from their start block, even before the DKG worker initializes them.
• Each session counts through its Commit phase and stops at quorumHeight + 5 * dkgPhaseBlocks. Rotated indices expire individually, not at the shared cycle mining window.
• If membership can't be determined (for example before v20), the session is counted, so zero never hides possible participation.
• Calls without a supplied or local proTxHash report zero.

No RPC fields are added. upcoming_dkgs is unchanged. The membership lookup is shared between active_dkgs and upcoming_dkgs, and CDKGDebugManager::GetSessionCount(), which lost its only caller, is removed.

Together with upcoming_dkgs, this lets dashpay/platform#5231 decide whether a masternode can stop safely from a single quorum dkginfo call.

How Has This Been Tested?

• test/functional/rpc_quorum.py: with DKG publication disabled, checks the count for a member and a non-member at the start block, inside the window, and after expiry, against the upcoming_dkgs predictions taken one block before the start.
• test/functional/feature_llmq_rotation.py: checks conservative counting of unknown membership before v20, zero counts despite expired debug sessions, and per-index expiry of rotated sessions at cycle offsets 0, 1, 9, 10, 11, 12 and 13.

Breaking Changes

active_dkgs stays numeric, but its meaning is corrected: it includes sessions not yet initialized locally, excludes expired sessions, counts unknown membership, and follows the supplied proTxHash. Clients that need the local DKG worker state should use quorum dkgstatus.

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 1cecaa40-3619-42fd-9d38-7a8de946b1cf

📥 Commits

Reviewing files that changed from the base of the PR and between c2c50fb and 1ed0310.

📒 Files selected for processing (4)

• doc/release-notes-7812.md
• src/llmq/debug.cpp
• src/llmq/debug.h
• src/rpc/quorums.cpp

💤 Files with no reviewable changes (2)

• src/llmq/debug.cpp
• src/llmq/debug.h

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 3 remain after this review.

---

Walkthrough

quorum dkginfo now computes active_dkgs from eligible current and upcoming sessions. It counts current sessions through the Commit phase and counts sessions with unknown membership conservatively. Upcoming entries report membership details when available or a reason when membership cannot be determined. Functional tests cover pre-v20 unknown membership, rotated membership, and upcoming type-100 membership. The release note describes the updated counting behavior.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~25 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant DkginfoRPC
  participant QuorumData
  Client->>DkginfoRPC: Request dkginfo
  DkginfoRPC->>QuorumData: Check cycle, work block, and membership
  QuorumData-->>DkginfoRPC: Membership result or unknown reason
  DkginfoRPC-->>Client: active_dkgs and upcoming DKG details

Loading

Merge Risk: ⚪ Minimal · up to 1ed03

The changed DKG participation count is consistent with session timing and membership selection. No issue requiring a fix before merge was established.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 11 functions across 4 files. (1 skipped: 1…	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Title check		The title clearly and concisely describes the main change: deriving the active DKG count from membership in the RPC.
Description check		The description directly explains the active_dkgs behavior change, implementation, testing, compatibility impact, and rationale.

Full details: Docstring Coverage

Explanation

Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 11 functions across 4 files. (1 skipped: 1 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

✅ Final review complete — no blockers (commit 1ed0310) · triage: normal

[thepastaclaw]

Final validation — Phase 2 only (queue backlog)

Verified the supplied Phase-2 claims against head ca29e24 and the four-commit PR range. No in-scope correctness blocker was identified; the commit-history suggestion is supported by the diffs and remains nonblocking. Validation was static only: the supplied CI snapshot shows successful formatting and merge checks, two queued container-manifest jobs, and cancelled conflict prediction; no local builds or tests were run.

🟡 1 suggestion(s)

1 finding(s) not shown inline (the lines are not part of this PR's diff)

🟡 Suggestion: Fold the active-window correction into the implementation it amends
<commit:ca29e24b74>:1

Commit ca29e24 replaces the dkgMiningWindowStart cutoff introduced by cbd8aa7 and retained by 0881935 with 5 * dkgPhaseBlocks, updates the newly added rotated-boundary assertions, and corrects the new current-session reason text. These changes complete the behavior introduced earlier in this same unmerged stack rather than repair behavior predating the PR. Fold this correction into the membership implementation, regrouping the implementation commits as needed; if the separate release-note commit is retained, consolidate its subsequent edits there. This follows the project's atomic-commit guidance and keeps permanent history focused on the complete intended behavior instead of its intermediate cutoff and immediate repair.

_{source: gpt-6.1-sol (phase2-reviewer: dash-core-commit-history)}

Review provenance

Source: reviewer 1: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: normal by gpt-6.1-sol (effort low) — The change adds nontrivial RPC membership prediction and per-session expiration logic with boundary tests, but does not itself alter consensus, funds movement, cryptography, network deserialization, or storage migrations.
• Phase 1 reviewers: not run (skipped for throughput: 13 PRs queued, above the 10 limit)
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — dash-core-commit-history (completed, effort high); agent phase2-reviewer

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `<commit:ca29e24b74>`:
- [SUGGESTION] <commit:ca29e24b74>:1: Fold the active-window correction into the implementation it amends
  Commit ca29e24b74 replaces the dkgMiningWindowStart cutoff introduced by cbd8aa7865 and retained by 08819354de with 5 * dkgPhaseBlocks, updates the newly added rotated-boundary assertions, and corrects the new current-session reason text. These changes complete the behavior introduced earlier in this same unmerged stack rather than repair behavior predating the PR. Fold this correction into the membership implementation, regrouping the implementation commits as needed; if the separate release-note commit is retained, consolidate its subsequent edits there. This follows the project's atomic-commit guidance and keeps permanent history focused on the complete intended behavior instead of its intermediate cutoff and immediate repair.

[thepastaclaw]

Re-review — Final validation — Phase 1 + Phase 2

Independently reviewed the complete diff at 31c1e47 and found no actionable in-scope defects. Membership-derived counts, conservative unknown handling, and per-index Commit-phase expiry match the surrounding selection and scheduling code; the prior commit-hygiene finding is fixed. This was a static review without local build or test execution; the supplied CI snapshot shows successful completed checks and four queued container builds.

🔴 0 blocking | 🟡 0 suggestion(s) | 💬 0 nitpick(s)

Review provenance

Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: normal by gpt-6.1-sol (effort low) — The change adds nontrivial RPC membership prediction and per-session boundary handling with regression tests, but does not change consensus, funds movement, cryptography, network deserialization, or storage migrations.
• Phase 1 reviewers: muse-spark-1.3-contributor — general (completed, effort xhigh); agent phase1-reviewer
• Phase 1 model: muse-spark-1.3-contributor — not quota-gated; passed over gemini-3.8-flash-high (antigravity below 15% reserve: weekly 15% left, 5h 100% left), glm-5.3-flash (not used above high effort; tier asks max)
• Fresh final gate: an independent Phase-2 review ran after iterative findings were reconciled
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — dash-core-commit-history (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — dash-core-commit-history (completed, effort high); agent phase2-reviewer

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify the current code and confirm that no unresolved issues remain.

No unresolved findings remain from the prior review on this head.

[knst]

what are all of these rpc fields in response are needed for?

simple rpc that answer to question about current active dkg sessions and upcoming suddenly returns so many things. That's not for debugging of dkg quorum process, that's for answering to simple trivial question "is masternode participating in dkg or could be safely rebooted / restarted"?

haveen't checked further more

[PastaPastaPasta]

@knst Agreed, the extra output wasn't needed. I removed active_dkg_sessions entirely (091b462). The PR now adds no RPC fields.

What's left is the fix to active_dkgs itself, so it answers "is this masternode in a DKG right now?" correctly:

• It counts sessions the given or local masternode is a member of from the start block, even before the DKG worker initializes them locally. Previously the count was 0 until the worker published its debug record, which is the gap that matters for safe restarts.
• It stops counting once a session's Commit phase ends, instead of keeping expired debug records.
• If membership can't be determined, the session is counted, so 0 never hides possible participation.

Together with your existing upcoming_dkgs, that's everything dashmate needs: stop only if active_dkgs == 0 and no member or unknown-membership DKG starts within the restart margin. dashpay/platform#5231 now uses exactly that.

---

🤖 Posted autonomously by Claude on behalf of pasta.

[thepastaclaw]

Re-review — Final validation — Phase 1 + Phase 2

Independently reviewed the complete PR diff at c2c50fb against the surrounding DKG lifecycle, membership-selection code, and functional-test setup; no actionable in-scope defects were found. The implementation counts membership through Commit, expires rotated indices independently, conservatively counts unknown membership, and preserves upcoming-session reporting. Validation was static only: the supplied CI snapshot shows successful preliminary checks, while container builds and conflict prediction remain queued; completed build and functional-test validation is not established.

🔴 0 blocking | 🟡 0 suggestion(s) | 💬 0 nitpick(s)

Review provenance

Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: normal by gpt-6.1-sol (effort low) — The change revises RPC participation-counting logic across DKG phase boundaries, rotated indices, and unknown membership with functional test coverage, but does not itself alter a critical surface.
• Phase 1 reviewers: muse-spark-1.3-contributor — general (completed, effort xhigh); agent phase1-reviewer
• Phase 1 model: muse-spark-1.3-contributor — not quota-gated; passed over gemini-3.8-flash-high (antigravity below 15% reserve: weekly 15% left, 5h 100% left), glm-5.3-flash (not used above high effort; tier asks max)
• Fresh final gate: an independent Phase-2 review ran after iterative findings were reconciled
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — dash-core-commit-history (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — dash-core-commit-history (completed, effort high); agent phase2-reviewer

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify the current code and confirm that no unresolved issues remain.

No unresolved findings remain from the prior review on this head.

[thepastaclaw]

Re-review — Final validation — Phase 1 + Phase 2

Independently reviewed the complete PR diff at 1ed0310 and verified the membership calculation, conservative unknown-membership handling, per-index Commit-phase expiry, and preservation of upcoming-session output; no actionable in-scope issues were found. The prior commit-organization finding is fixed: the correction and regression coverage are incorporated into the implementation commit. Validation was static only; the supplied CI snapshot reports successful completed builds, lint, and standard Linux, SQLite, and no-wallet tests, with ASan tests, TSan tests, and the multiprocess build still pending.

🔴 0 blocking | 🟡 0 suggestion(s) | 💬 0 nitpick(s)

Review provenance

Source: reviewer 1: gemini-3.8-flash-high (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); reviewer 4: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 5: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)

• Triage: normal by gpt-6.1-sol (effort low) — The change revises RPC counting logic across DKG membership, phase boundaries, and rotated-session expiry with functional coverage, but does not itself alter consensus, funds, cryptography, network deserialization, or storage migrations.
• Phase 1 reviewers: gemini-3.8-flash-high — general (completed, effort high); agent phase1-reviewer
• Phase 1 model: gemini-3.8-flash-high — antigravity quota: weekly 59% left, 5h 39% left
• Fresh final gate: an independent Phase-2 review ran after iterative findings were reconciled
• Fresh verifier: gpt-6.1-sol — final-verifier; agent sol-verifier
• Phase 2 reviewers: gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — dash-core-commit-history (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — general (completed, effort high); agent phase2-reviewer, gpt-6.1-sol — dash-core-commit-history (completed, effort high); agent phase2-reviewer

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify the current code and confirm that no unresolved issues remain.

No unresolved findings remain from the prior review on this head.

[PastaPastaPasta]

approved; this looks reasonable; should fix an edge case bug in dashmate