feat: migrate to ic-cdk 0.20 - #11069
Draft
nmattia wants to merge 2 commits into
Draft
Conversation
This builds on recent work and completes the migration to ic-cdk 0.20 (0.20.2 to be precise). This introduces a dependency on the new (extracted) crate `ic-cdk-management-canister`. Important note: the `GetUtxosRequest` exported by `bitcoin_canister` does _not_ implement `Clone` or `Ord` anymore, though we rely on it for BTreeMap ordering. To avoid breaking any sort of compatibility, we wrap this new type in a newtype and have a custom implementation with the same behavior as the old type. One note: the old ic-cdk version 0.19 is still pulled in transitively via `ic-canister-runtime`. This will be handled separately.
Contributor
Author
|
This requires #11055 to merge first |
pull Bot
pushed a commit
to mikeyhodl/ic
that referenced
this pull request
Aug 10, 2026
… 0.20 (dfinity#11073) <!-- ccr-slack-attribution --> _Requested by **Nicolas Mattia, Mathias Björkqvist** · [Slack thread](https://dfinity.slack.com/archives/CL7Q2RXUM/p1786105631218959?thread_ts=1786105631.218959&cid=CL7Q2RXUM)_ ## Summary Bump the `ic-canister-runtime` pin in the root `Cargo.toml` from `0.2.0` to `0.2.3` so that `canhttp` (and anything depending on it) stops pulling in `ic-cdk 0.19` transitively. **Before:** `ic-canister-runtime = "0.2.0"` (resolves to `0.2.1` in `Cargo.lock`), which depends on `ic-cdk 0.19.0`. `canhttp`'s latest release already moved to `ic-cdk 0.20` + `ic-canister-runtime`, but because `ic-canister-runtime` itself was pinned to an old version here, that path kept resolving back down to `ic-cdk 0.19`. **After:** `ic-canister-runtime = "0.2.3"` (the latest version on crates.io as of this PR), which depends on `ic-cdk ^0.20.1`. This lets `canhttp` and its dependents resolve onto `ic-cdk 0.20` instead of `0.19`. Related/context: - dfinity#11069 — migrates the direct `ic-cdk` dependency to `0.20.2`, but explicitly leaves this transitive path through `ic-canister-runtime` for later ("This will be handled separately"). - dfinity#11055 — prerequisite for dfinity#11069 (migrates remaining `ic-cdk::call` call sites to the new `Call` API). - Neither dfinity#11069 nor dfinity#11055 touches the `ic-canister-runtime` pin, so this PR is complementary, not redundant, and can land independently of them. ## Changes - `Cargo.toml`: `ic-canister-runtime = "0.2.0"` → `"0.2.3"` - `bazel/rust.MODULE.bazel`: matching `crate.spec(package = "ic-canister-runtime", version = "^0.2.0")` → `"^0.2.3"` ## Known limitation / what still needs to happen in CI `Cargo.lock` and the Bazel crate-index lockfiles (`Cargo.Bazel.json.lock` / `Cargo.Bazel.toml.lock`) are **not** regenerated in this PR. Regenerating them (`cargo update`, `./bin/bazel-pin.sh`) requires fetching workspace git dependencies (e.g. `dfinity-lab/build-info`, used elsewhere in the workspace) that this sandbox environment cannot reach, and `bazel` itself is not available in the sandbox. I expect CI's lockfile-autofix job to regenerate both lockfiles against this `Cargo.toml`/`MODULE.bazel` change. ## How Verified Confirmed on crates.io that `ic-canister-runtime 0.2.3` is the latest published version and its `Cargo.toml` depends on `ic-cdk ^0.20.1` (not `0.19`). Could not run `cargo check` / `bazel build` locally for the reason above — please rely on CI for the actual lockfile regeneration and build/test verification. --------- Co-authored-by: Claude <noreply@anthropic.com> 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
1 participant
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.
This builds on recent work and completes the migration to ic-cdk 0.20 (0.20.2 to be precise).
This introduces a dependency on the new (extracted) crate
ic-cdk-management-canister.Important note: the
GetUtxosRequestexported bybitcoin_canisterdoes not implementCloneorOrdanymore, though we rely on it for BTreeMap ordering. To avoid breaking any sort of compatibility, we wrap this new type in a newtype and have a custom implementation with the same behavior as the old type.One note: the old ic-cdk version 0.19 is still pulled in transitively via
ic-canister-runtime. This will be handled separately.