feat: allow unlimited number of gen4 nodes#10448
Conversation
There was a problem hiding this comment.
Pull request overview
This PR modifies the registry canister’s node-add flow to relax max_rewardable_nodes enforcement for certain Gen4 node reward types, enabling node providers to register more cloud/on-demand nodes (while explicitly keeping type4.5 subject to the existing quota rule).
Changes:
- Bypasses the
max_rewardable_nodesquota check when adding nodes of reward typestype4.1–type4.4. - Keeps the quota check enforced for
type4.5. - Adds unit tests covering the bypass behavior for
type4.1–type4.4and continued enforcement fortype4.5.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
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 74ce942. Security Overview
Detected Code Changes
|
daniel-wong-dfinity-org-twin
left a comment
There was a problem hiding this comment.
Seems like, this could cause problems space problems in the Registry canister... I mean, an alternative is just to have a very large (but finite!) limit, right??
| // Validate node operator's max_rewardable_nodes quota. | ||
| let num_remaining_nodes = | ||
| num_in_registry_same_type.saturating_sub(num_removed_same_ip_same_type); | ||
| if num_remaining_nodes >= max_rewardable_nodes_same_type { |
There was a problem hiding this comment.
did you get an answer on whether == max is bad? Seems like the original code (where == max was considered bad) was buggy. If it is bad, I'd like to know why, but I'm not going to block on this, because at least we are not regressing; if it was a bug before, at least we are not introducing a NEW bug.
It is probably worth explaining in comments why == max is considered bad, because that is highly unintuitive.
This pull request allows node providers to add more type4.x nodes (excluding type4.5 for now see #10393).
This is needed to allow for provisioning on-demand nodes in the cloud and registering them with the network.