feat(governance): clear voting power snapshots on Mission 70 activation#9731
feat(governance): clear voting power snapshots on Mission 70 activation#9731jasonz-dfinity merged 3 commits intomasterfrom
Conversation
When Mission 70 activates, voting power distribution changes significantly (convex dissolve delay bonus, reduced max dissolve delay). Stale snapshots from before activation would cause false spike detections, since the new voting power totals will differ substantially from the old ones. - Add VotingPowerSnapshots::clear() method that empties both stable BTreeMaps - Call it during governance initialization when the Mission 70 flag is enabled - Add a log line when a voting power spike is detected for observability - Add unit test for clear() verifying both maps are emptied
There was a problem hiding this comment.
This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):
-
Update
unreleased_changelog.md(if there are behavior changes, even if they are
non-breaking). -
Are there BREAKING changes?
-
Is a data migration needed?
-
Security review?
How to Satisfy This Automatic Review
-
Go to the bottom of the pull request page.
-
Look for where it says this bot is requesting changes.
-
Click the three dots to the right.
-
Select "Dismiss review".
-
In the text entry box, respond to each of the numbered items in the previous
section, declare one of the following:
-
Done.
-
$REASON_WHY_NO_NEED. E.g. for
unreleased_changelog.md, "No
canister behavior changes.", or for item 2, "Existing APIs
behave as before.".
Brief Guide to "Externally Visible" Changes
"Externally visible behavior change" is very often due to some NEW canister API.
Changes to EXISTING APIs are more likely to be "breaking".
If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.
If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.
Reference(s)
For a more comprehensive checklist, see here.
GOVERNANCE_CHECKLIST_REMINDER_DEDUP
There was a problem hiding this comment.
Pull request overview
This PR addresses Mission 70 governance rollout by resetting persisted voting power snapshot state to avoid false-positive spike detection when voting power distribution shifts at activation.
Changes:
- Added
VotingPowerSnapshots::clear()to empty both snapshot stable maps. - Cleared voting power snapshots during governance restore when the Mission 70 flag is enabled.
- Added a log line when a voting power spike is detected, plus a unit test for
clear().
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| rs/nns/governance/src/governance/voting_power_snapshots.rs | Adds spike observability log and a clear() method to reset snapshot storage. |
| rs/nns/governance/src/governance/voting_power_snapshots_tests.rs | Adds a unit test intended to validate clear() behavior. |
| rs/nns/governance/src/governance.rs | Invokes snapshot clearing during Governance::new_restored when Mission 70 is enabled. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…ration Move VOTING_POWER_SNAPSHOTS clearing inside the existing dissolve-delay-clamping block, which uses neuron_id_to_pre_clamp_dissolve_state.is_empty() as an idempotency guard. This ensures snapshots are only cleared once on first M70 activation, not on every subsequent upgrade. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- behind feature flag
- not breaking
- N/A
- will review before turning on feature flag
Summary
VotingPowerSnapshots::clear()method that empties both stable BTreeMapsclear()verifying both maps are emptiedWhy
When Mission 70 activates, voting power distribution changes significantly (convex dissolve delay bonus, reduced max dissolve delay). Stale snapshots from before activation would cause false spike detections, since the new voting power totals will differ substantially from the old ones.
Test plan
VotingPowerSnapshots::clear()verifying both maps are emptied