refactor(cmc): replace private management canister types with public crate#9276
refactor(cmc): replace private management canister types with public crate#9276jasonz-dfinity wants to merge 4 commits intomasterfrom
Conversation
…crate Switch CMC from ic-management-canister-types-private (internal replica types) to ic-management-canister-types (public crate from crates.io). This eliminates the version-skew risk where new fields in the private crate CanisterSettingsArgs silently become part of CMC external Candid API. Also removes log_memory_limit from cmc.did -- it was never used by CMC and leaked from the private types CanisterSettingsArgs.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
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
CMC now re-exports CanisterSettings from the public ic-management-canister-types crate (as CanisterSettingsArgs). Update downstream consumers that construct this type: - rs/sns/cli: replace BoundedVec with Vec<Principal> for controllers - rs/nns/integration_tests: replace CanisterSettingsArgsBuilder with struct literals using the public type
…xport Drop the alias -- re-export CanisterSettings directly from the public crate instead of aliasing it as CanisterSettingsArgs. Update all downstream consumers.
jasonz-dfinity
force-pushed
the
jason/replace-private-mgmt-types-cmc
branch
from
4654ed6 to
bec4ba7
Compare
1 participant
Why
CMC re-exports
CanisterSettingsArgsfrom the privateic-management-canister-types-privatecrate, which is the internal replica type definition. New fields added to that struct (e.g.log_memory_limit,snapshot_visibility) silently become part of CMC's external Candid API and get forwarded to the management canister, even if the replica doesn't support them yet. Switching to the publicic-management-canister-typescrate decouples CMC from internal replica type churn.What
ic-management-canister-types-privatedependency withic-management-canister-types(public crate from crates.io) in both Cargo.toml and BUILD.bazelCanisterSettingsArgsBuilder),candid::Principal::management_canister()instead ofIC_00, string literals instead ofMethod::*enum variantslog_memory_limitfromcmc.did— it was never used by CMC and leaked from the private crate'sCanisterSettingsArgsTesting
Existing unit and DID-compatibility tests cover the changed code paths.