feat: Add a cooling_down field to SubnetRecord - #11236
Conversation
548e78f to
d226387
Compare
See the doc comment of `ic_replicated_state::SubnetTopology::cooling_down` for the semantics of a subnet "cooling down". The new registry field backs that flag, which used to be hardcoded to `false` because no registry field was backing it. The field can be set via `UpdateSubnetRecord` governance proposals; the engine controller is deliberately kept out of scope (it may only set `subnet_admins` and `is_halted`). The field must not be set in prod until #11117, which introduced the new error code for ingress messages rejected on cooling down subnets (`ErrorCode::SubnetCoolingDown`), is rolled out to all subnets on mainnet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
d226387 to
d00beed
Compare
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
|
✅ No security or compliance issues detected. Reviewed everything up to d00beed. Security Overview
Detected Code Changes
|
|
✅ No security or compliance issues detected. Reviewed everything up to d00beed. Security Overview
Detected Code Changes
|
The field can be set via
UpdateSubnetRecordgovernance proposals (the engine controller is deliberately kept out of scope: it may only setsubnet_adminsandis_halted) and is now read intoSubnetTopology::cooling_down, which used to be hardcoded tofalsebecause no registry field was backing it.The field must not be set in prod until #11117, which introduced the new error code for ingress messages rejected on cooling down subnets (
ErrorCode::SubnetCoolingDown), is rolled out to all subnets on mainnet.