Ic-cdk 0.19.0-beta.3 is released

Developers
1

Hi folks, a set of beta releases for ic-cdk 0.19 are now available:

ic-cdk = "0.19.0-beta.3"
ic-cdk-timers = "1.0.0-beta.1"

Async/await

The most consequential change is the new async executor. The 0.18 executor introduced new capabilities, and one of them is a footgun: the ability for a task to suspend during one canister method and resume during another. In 0.19 this is prevented: a task will only resume during the method that spawned it, and if the method ends before the task has completed, it will panic.

New related functions are also added: spawn_weak will spawn tasks that cancel when they outlast the canister method, and spawn_migratory opts into the ability to outlast the canister method, keeping the behavior from 0.18. In the future we intend to forbid spawn_migratory tasks from calling functions beginning with msg_*, which are the primary footgun.

If you are using inter-canister calls in conventional ways (including composing them with futures’ FuturesUnordered and other abstractions around futures) this should not affect you. If it does affect you, please report it as a bug. It should only affect complex use cases involving channels or other similar manually-triggered futures. It should in particular not be possible for this to affect any code that worked in 0.17.

Canister environment variables

This release supports the canister side of the new canister environment variables API. Canister environment variables are a key-value map that can be read and written by the canister and by external tools. You can use these for any kind of controller-updatable settings that you don’t want to go to the effort of building an API and storage mechanism into your canister for.

We intend eventually to make it easy to use these to store principals for canisters you make inter-canister calls to, instead of baking that information into the WASM. This will allow bindings generators to not need to talk to dfx, and eliminate the requirement for different builds for local dev and mainnet.

Timers

Timer bodies are now async. You have probably written a lot of timers that looked like this:

set_timer(|| {
    spawn(async {
        make_call().await;
    })
})

Now, this can be shortened to:

set_timer(async {
    make_call().await;
})

You might also notice that the new ic-cdk-timers version is 1.0.0 rather than an 0.x release. Going forwards, ic-cdk-timers does not depend on ic-cdk, and will not need to be updated when ic-cdk updates. This will enhance compatibility between libraries using different versions of the CDK.

Please try out these new versions and let us know if you encounter any issues!

8 Likes
2

Hi @AdamS , I got error for deployment:
```
The replica returned a rejection error: reject code CanisterError, reject message Error from Canister dpjyw-raaaa-aaaar-qbxlq-cai: Canister’s Wasm module is not valid: Wasm module has an invalid import section. Module imports function ‘__wbindgen_describe’ from ‘_wbindgen_placeholder_’ that is not exported by the runtime..

If you are running this canister in a test environment (e.g., dfx), make sure the test environment is up to date. Otherwise, this is likely an error with the compiler/CDK toolchain being used to build the canister. Please report the error to IC devs on the forum: https://forum.dfinity.org and include which language/CDK was used to create the canister., error code Some(“IC0505”)
```

Project: GitHub - ldclabs/ic-one-bridge: đŸȘ™ An Internet Computer canister to bridge ERC-20 & ICRC tokens.

3

This error is unrelated to the CDK. You will get this error when attempting to use a dependency that thinks WASM means the browser. If you have enabled a dependency’s ‘wasm support’ via a Cargo feature, especially if that feature is particularly named wasm-bindgen, that is the source of the error. If you are trying to use reqwest, tokio, or ic-agent, you cannot; if you are trying to use rand, or anything that requires getrandom, there is some setup required.

Edit: I see you were handling the getrandom part with a crate. Unfortunately that crate is using getrandom 0.2 and is not updated to 0.3, and your dependencies are using getrandom 0.3. However, it looks like the actual issue is your alloy dependency, which unconditionally uses reqwest and other browser wasm primitives like wasmtimer (cargo tree -p ic-one-bridge -i wasm-bindgen --target all)

4

@AdamS , really appreciate the spot-on feedback! I’ve fixed it up. :blush:

5

@cryptoschindler What’s your opinion here ? Shouldn’t we review also those library ?

6

No, I don’t think this is necessary.

7

@AdamS I suspect there is a bug in ic-cdk “0.19.0-beta.3”: when installing the wasm built by GitHub, the post_upgrade arguments do not take effect. However, deploying locally with dfx works as expected.

Reproduction steps:

  1. Use the project https://github.com/ldclabs/ic-one-bridge, which uses ic-cdk “0.19.0-beta.3”.

  2. Deploy the initial version locally:

dfx deploy one_bridge_canister
  1. Check canister info:
dfx canister call one_bridge_canister info '()'

At this point: min_threshold_to_bridge: 100_000_000

  1. Download the GitHub-built version and perform an upgrade install:
wget https://github.com/ldclabs/ic-one-bridge/releases/download/v0.3.2/one_bridge_canister.wasm.gz

dfx canister install --mode upgrade --wasm debug/one_bridge_canister.wasm.gz --argument '(opt variant {Upgrade =
  record {
    min_threshold_to_bridge = opt 1_000_000_000;
  }
})' one_bridge_canister
  1. Check canister info again:
dfx canister call one_bridge_canister info '()'

At this point: min_threshold_to_bridge: 100_000_000 remains unchanged, indicating that the post_upgrade arguments did not take effect.

8

PING @AdamS : This could be a serious bug.

9

This appears to be an issue with dfx canister install --wasm. Many ‘environmental’ properties are ignored with --wasm; one of them is the Candid interface of the local project. The arguments are serialized as-is, with the default types if explicit types are not provided, and the default type of an int literal is int. If you annotate that opt 1_000_000_000: opt nat, or even 1_000_000_000: nat, the issue disappears. It is also absent when using regular dfx canister install without --wasm (if you were using a second wasm module to get around dfx ignoring upgrade requests for identical hashes, that is what the --upgrade-unchanged flag is for). I do not believe this is any different between CDK versions 0.18 and 0.19, but thank you for the dfx bug report all the same.

2 Likes
10

That’s exactly the cause.