feat(root): New method: create_canister_and_install_code#9610
Merged
daniel-wong-dfinity-org merged 4 commits intomasterfrom Apr 7, 2026
Merged
Conversation
daniel-wong-dfinity-org
changed the title
jasonz-dfinity
approved these changes
Mar 26, 2026
![github-actions[bot]](https://avatars.gh.lumenfield.work/in/15368?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
daniel-wong-dfinity-org
dismissed
github-actions[bot]’s stale review
- Done.
- Non-breaking; new API.
- Root has no persistent data.
- Requesting...
…s part of create_canister_and_install_code).
daniel-wong-dfinity-org
force-pushed
the
create_canister_and_install_code-root-daniel-wong
branch
from
9ab868c to
c70888a
Compare
daniel-wong-dfinity-org
deleted the
create_canister_and_install_code-root-daniel-wong
branch
github-merge-queue bot
pushed a commit
that referenced
this pull request
Apr 9, 2026
…9611) This is behind a flag, which per usual, is off in production. This includes changes to .did, .proto, as well as actual executable implementation, including validation. # Prior Work This new proposal type overlaps a bit with the existing NnsCanisterInstall proposal type. This differs in a couple of key ways: 1. The created canister can live in other subnets. 2. The created canister is NOT designated as an NNS canister (in Registry). # Implementation This is a direct proposal action. This is because we implement validation (which would require Decode if this were instead done as an `NnsFunction`). This follows the usual pattern of adding a new `.rs` file to the `proposals` dir, dedicated to the new proposal type. Within that file we have various `impl` blocks for the new proposal type, including `impl`s for various traits. Calls a new method of the Root canister, aptly named `create_canister_and_install_code`. See "References". As usual, Root does the real work. Un-nested `CanisterSettings` from within `UpdateCanisterSettings` so that it can be shared with `CreateCanisterAndInstallCode`. A large chunk of the changes here are mechanical type conversions. # Testing Not yet tested, but since this is behind a flag, it should be fine for this code to be deployed (and in the master branch). # References [👈 Previous PR][prev] [prev]: #9610 --------- Co-authored-by: IDX GitHub Automation <infra+github-automation@dfinity.org>
daniel-wong-dfinity-org
added a commit
that referenced
this pull request
Apr 15, 2026
…9611) This is behind a flag, which per usual, is off in production. This includes changes to .did, .proto, as well as actual executable implementation, including validation. # Prior Work This new proposal type overlaps a bit with the existing NnsCanisterInstall proposal type. This differs in a couple of key ways: 1. The created canister can live in other subnets. 2. The created canister is NOT designated as an NNS canister (in Registry). # Implementation This is a direct proposal action. This is because we implement validation (which would require Decode if this were instead done as an `NnsFunction`). This follows the usual pattern of adding a new `.rs` file to the `proposals` dir, dedicated to the new proposal type. Within that file we have various `impl` blocks for the new proposal type, including `impl`s for various traits. Calls a new method of the Root canister, aptly named `create_canister_and_install_code`. See "References". As usual, Root does the real work. Un-nested `CanisterSettings` from within `UpdateCanisterSettings` so that it can be shared with `CreateCanisterAndInstallCode`. A large chunk of the changes here are mechanical type conversions. # Testing Not yet tested, but since this is behind a flag, it should be fine for this code to be deployed (and in the master branch). # References [👈 Previous PR][prev] [prev]: #9610 --------- Co-authored-by: IDX GitHub Automation <infra+github-automation@dfinity.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Only callable by governance.
As usual, this does the "real work" of a new upcoming proposal type that creates a new canister in a non-NNS subnet (and install code into the new canister).
Prior Work
This new proposal type overlaps a bit with the existing
NnsCanisterInstallproposal type. This differs in a couple of key ways:Behavior Details
This uses bounded wait so that NNS (Root and Governance canisters) does not get stuck as a result of an unresponsive subnet (either because it is malicious, or otherwise messed up).
The canister is created using cycles from the Root canister's balance. This is like how when SNS-WASM creates canisters, cycles are taken from its own balance. Keeping Root topped up is beyond the scope of this feature.
Testing
No tests yet. Those will be in a future PR. This is ok, because only Governance is allowed to call this new method, and no code path in Governance calls it yet.
References
Closes NNS1-4342.
Next PR 👉