Skip to content

chore: support canister migration from/to deleted subnet in registry#10470

Open
mraszyk wants to merge 5 commits into
masterfrom
mraszyk/migrate-canisters-on-deleted-subnets-in-registry
Open

chore: support canister migration from/to deleted subnet in registry#10470
mraszyk wants to merge 5 commits into
masterfrom
mraszyk/migrate-canisters-on-deleted-subnets-in-registry

Conversation

@mraszyk

@mraszyk mraszyk commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

This PR supports canister migration from/to deleted subnet in the registry by:

  • adding a test that canister migration from a deleted (source) subnet succeeds (the implementation already supports this case so we just add a test to prevent a regression);
  • skipping updating the deleted target subnet in the routing table (the canister migration is still successful since the outcome should be as if the migration completed first and the subnet was only deleted later) and adding a test covering this case.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

This PR updates the registry canister’s canister-migration logic to tolerate migrations involving subnets that have been deleted from the registry/routing table, and adds regression tests to lock in the behavior.

Changes:

  • Adjust routing-table mutation so migrating to a target subnet that is absent from the routing table does not leave any ranges assigned to that (deleted) target subnet.
  • Relax payload validation to allow migrations to target subnets that no longer exist in the registry.
  • Add/extend unit tests covering migration when the source subnet is “deleted” (unrouted gap) and when the target subnet does not exist.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File Description
rs/registry/canister/src/mutations/routing_table.rs Skips persisting assignments to a target subnet that has no existing ranges in the routing table.
rs/registry/canister/src/mutations/do_migrate_canisters.rs Removes target-subnet existence validation and adds tests for deleted-source / deleted-target migration scenarios.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread rs/registry/canister/src/mutations/routing_table.rs Outdated
Comment thread rs/registry/canister/src/mutations/do_migrate_canisters.rs Outdated
Comment thread rs/registry/canister/src/mutations/do_migrate_canisters.rs
mraszyk and others added 4 commits June 15, 2026 12:18
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
@mraszyk mraszyk marked this pull request as ready for review June 15, 2026 11:17
@mraszyk mraszyk requested a review from a team as a code owner June 15, 2026 11:17

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

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

@mraszyk

mraszyk commented Jun 15, 2026

Copy link
Copy Markdown
Contributor Author

I believe this PR is not worth an entry in the changelog...

@zeropath-ai

zeropath-ai Bot commented Jun 15, 2026

Copy link
Copy Markdown

No security or compliance issues detected. Reviewed everything up to 7e5ff24.

Security Overview
Detected Code Changes
Change Type Relevant files
Refactor ► rs/registry/canister/src/mutations/do_migrate_canisters.rs
    Remove unnecessary validation for target subnet existence in do_migrate_canisters
    Add test for migrating canisters when the source subnet is deleted
    Add test for migrating canisters to a non-existent target subnet
► rs/registry/canister/src/mutations/routing_table.rs
    Modify routing table assignment to handle non-existent target subnets
Enhancement ► rs/registry/canister/src/mutations/do_migrate_canisters.rs
    Update test to include dedicated range for target subnet
    Update test assertion for routing table split around migrated canister

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants