Skip to content

feat: Rate limit subnet admin updates#9292

Open
dsarlis wants to merge 2 commits intodfinity:masterfrom
dsarlis:dimitris/rate-limit
Open

feat: Rate limit subnet admin updates#9292
dsarlis wants to merge 2 commits intodfinity:masterfrom
dsarlis:dimitris/rate-limit

Conversation

@dsarlis
Copy link
Contributor

@dsarlis dsarlis commented Mar 10, 2026

This PR implements a rate limit on the number of subnet admin updates that can happen per subnet on a daily basis. The limit is on a subnet level to avoid having a situation where updates in one rented subnet affect another.

However, if needed a global limit can be added on top of the current one with relative ease as the rate limiter library allows for such compositions. This is left for future as for now the per subnet one should provide a good enough safety net.

@dsarlis dsarlis requested a review from a team as a code owner March 10, 2026 13:59
Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):

  1. Update unreleased_changelog.md (if there are behavior changes, even if they are
    non-breaking).

  2. Are there BREAKING changes?

  3. Is a data migration needed?

  4. Security review?

How to Satisfy This Automatic Review

  1. Go to the bottom of the pull request page.

  2. Look for where it says this bot is requesting changes.

  3. Click the three dots to the right.

  4. Select "Dismiss review".

  5. 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

@dsarlis
Copy link
Contributor Author

dsarlis commented Mar 10, 2026

  1. Updated unreleased_changelog.md.
  2. The change is backwards compatible as it adds one more case where things fail but nothing changes on the interface level.
  3. No data migration needed.
  4. Security review is up to you.

@basvandijk basvandijk added the security-review-passed IDX or InfraSec have concluded it's safe to run CI on the external PR. label Mar 10, 2026
@github-actions
Copy link
Contributor

@github-actions
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

external-contributor feat @governance-team security-review-passed IDX or InfraSec have concluded it's safe to run CI on the external PR.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants