dfinity / cdk-rs Goto Github PK

See: https://github.com/dfinity/cdk-rs/blob/main/src/ic-certified-map/CHANGELOG.md

But it is certainly out in the wild: https://docs.rs/ic-certified-map/0.2.0/ic_certified_map

The [Unreleased] section is touched by 2112e91, which is post-0.2.0.

As a side-request, can we have a new release from main? dfinity/ic won't build with "0.2.0" as some trait derivations are missing.

counter.rs

#[derive(CandidType, Deserialize)]
struct OwnerResult {
    canister_id: candid::Principal,
}

#[query]
fn owner() -> OwnerResult{
    unsafe {
        OwnerResult{
            canister_id: candid::Principal::management_canister()
        }
    }
}

service : {
  "owner": () -> (OwnerResult) query;
}

In another file, I can't just return CounterCanister::owner().await.0.canister_id:
It's expecting principal to be a vec of bytes, rather than a principal. The following code below compiles but then returns an error at runtime...

service : {
  "owner": () -> (principal) query;
}

#[import(canister = "counter_rs")]
struct CounterCanister;

#[query]
async fn owner() ->  candid::Principal {
    
        let b = CounterCanister::owner().await.0;
        let (a,): (candid::Principal,) = decode_args(&b.canister_id).unwrap();
        a
    
}

Are there any workarounds currently?

It shows () only without the content

Does the CDK allow back traces, or is there a more native way to enable them within a canister? I am getting a panic from a dependency, and the canister logs do not give me any kind of back trace. More information here: https://forum.dfinity.org/t/rust-canister-backtraces/6353/3

I am going through a lot of difficulties getting proptest to compile for the IC, and having backtraces would really help I imagine.

it would be great if we could support version flag return properly.

# current
$ ic-cdk-optimizer --version
ic-cdk-optimizer

# expected
$ ic-cdk-optimizer --version
ic-cdk-optimizer 0.3.3

Forum post: https://forum.dfinity.org/t/management-canister-not-found/9049

I am using dfx v0.8.4. I am trying to do a cross-canister call to the management canister like I've done before:

let call_result: Result<(Vec<u8>,), _> = ic_cdk::api::call::call(
    ic_cdk::export::Principal::management_canister(),
    // ic_cdk::export::Principal::from_text("aaaaa-aa").unwrap(),
    "raw_rand",
    ()
).await;

Each way of calling the management canister above (one is commented out) results in the following error:

[Canister rrkah-fqaaa-aaaaa-aaaaq-cai] Panicked at 'called `Result::unwrap()` on an `Err` value: (DestinationInvalid, "Canister o5alr-fkgwv-ukoa3-em3wh-7cj4t-ngizi-krl3c-v44po-ar5jg-a5agw-pqe not found")', canisters/call/src/lib.rs:125:44

Hey,

there are a lot of documentation about Motoko and their guarantees (single threaded, after trap state will be reverted, ...) but I haven't found any information about cdk-rs on this topic and I don't really know if there are big differences between CDK and Motoko regarding request-processing and guarantees (like state will be reverted when trap happens/ what is a trap in cdk-rs, panic?). A comparison would be great I think.

Here is the original question in : dfinity-forum

It would be great if someone can elaborate more on this topic.

Hey!

I am trying to use the import macro attribute. I have a Rust canister and a Motoko canister. The motoko canister is named motoko. I am trying to use the macro like this:

#[import(canister = "motoko")]
struct MotokoCanister;

async fn customGet(id: ID) -> Result<Option<Message>, sudograph::async_graphql::Error> {
    return Ok(MotokoCanister::customGet(id.to_string()).await.0);
}

Here's the Motoko source code for the canister:

import Text "mo:base/Text";
import Map "mo:base/HashMap";
import Option "mo:base/Option";

actor Motoko {
    let message_store = Map.HashMap<Text, ?Message>(10, Text.equal, Text.hash);

    type Message = {
        id: Text;
        text: Text;
    };

    public query func customGet(id: Text): async ?Message {
        let message: Message = {
            id = "0";
            text = "motoko";
        };

        return Option.make(message);
    }
}

The problem seems to be that I have a Message type defined already in my Rust canister. I need to define the type because it is my own custom type used throughout the Rust canister. The import attribute seems to also be defining the type to provide the interoperability between the canisters. Something doesn't seem right about the import implementation in this case.

I am getting multiple errors like the following:

error[E0428]: the name `Message` is defined multiple times
 --> canisters/graphql/src/graphql.rs:6:1
  |
4 | graphql_database!("canisters/graphql/src/schema.graphql");
  | ---------------------------------------------------------- previous definition of the type `Message` here
5 | 
6 | #[import(canister = "motoko")]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `Message` redefined here
  |
  = note: `Message` must be defined only once in the type namespace of this module
  = note: this error originates in an attribute macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0119]: conflicting implementations of trait `std::clone::Clone` for type `Message`
 --> canisters/graphql/src/graphql.rs:6:1
  |
4 | graphql_database!("canisters/graphql/src/schema.graphql");
  | ---------------------------------------------------------- first implementation here
5 | 
6 | #[import(canister = "motoko")]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `Message`
  |
  = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

I am new here and want to contribute to the development of Dfinity community.
can we have a certain repository like Dfinity community for members like me to publish events or webinars and sharing these infos here.
understand that's forums and websites or meetup to do so, but I still recommend to have such a repository here on Github.

#36

All cycles API from CDK should use unsigned numbers.

I would like to build an app on IC with an iOS frontend. When attempting to call the Hello World sample from the iOS frontend, I got this error:

thread '' panicked at 'debug_print should only be called inside canisters.', /Users/Ayman/.cargo/registry/src/github.com-1ecc6299db9ec823/ic-cdk-0.3.0/src/api/ic0.rs:60:1
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
libc++abi: terminating with uncaught foreign exception

The canister was deployed to the local replica. Any suggestions? Thanks.

#[inspect_message]
async fn inspect_message() {
ic_cdk::api::call::accept_message();
let event_canister_id = Principal::from_text("rkp4c-7iaaa-aaaaa-aaaca-cai").unwrap();
let result:CallResult<()> = ic_cdk::api::call::call(event_canister_id,"createEvent",()).await;
}
I tried to call in the inspect_message, but failed, but it works normally in the function of update type. This is an error returned. Does anyone know how to solve it.

The replica returned an HTTP Error: Http Error: status 500 Internal Server Error, content type "", content: Requested canister failed to process the message acceptance request

Hello!

i'm trying to create rust application like it described in your tutorial
https://sdk.dfinity.org/docs/quickstart/network-quickstart.html

so, i have started local network with dfx start
i have updated application created with rust_hello command like it described in guide

but after running dfx deploy command i received next error

crawter@PC:~/rust_hello/src/rust_hello$ dfx deploy
Deploying all canisters.
Creating canisters...
Creating canister "rust_hello"...
Creating the canister using the wallet canister...
Creating a wallet canister on the local network.
The wallet canister on the "local" network for user "default" is "rwlgt-iiaaa-aaaaa-aaaaa-cai"
"rust_hello" canister created with canister id: "rrkah-fqaaa-aaaaa-aaaaq-cai"
Building canisters...
Executing 'cargo build --target wasm32-unknown-unknown --package rust_hello'
thread 'main' panicked at 'Could not run custom tool.: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/dfx/src/lib/builders/custom.rs:181:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

would you kindly tell me what could be wrong?
my dfx.json

{
  "canisters": {
    "rust_hello": {
      "build": "cargo build --target wasm32-unknown-unknown --package rust_hello",
      "candid": "src/rust_hello/rust_hello.did",
      "wasm": "target/wasm32-unknown-unknown/debug/rust_hello.wasm",
      "type": "custom"
    }
  },
  "defaults": {
    "build": {
      "packtool": ""
    }
  },
  "dfx": "0.6.25",
  "networks": {
    "local": {
      "bind": "127.0.0.1:8000",
      "type": "ephemeral"
    },
    "ic": {
      "providers": [
        "https://gw.dfinity.network"
      ],
      "type": "persistent"
    }
  },
  "version": 1
}

rust_hello/src/rust_hello/Cargo.toml

[package]
name = "rust_hello"
version = "0.1.0"
authors = ["Your Name <[email protected]>"]
edition = "2018"

[lib]
path = "main.rs"
crate-type = ["cdylib"]

[dependencies]
ic-cdk = { path = "../../../cdk-rs/src/ic-cdk", version = "0.1.0" }
ic-cdk-macros = { path = "../../../cdk-rs/src/ic-cdk-macros", version = "0.1.0" }

cdk-rs and rust_hello are situated in the same folder

The code is:

#[derive(CandidType, Copy, Clone, Deserialize)]
struct SetNodeArgs<'a> {
    pub_key: &'a [u8],
    auth: bool
}
...

#[update]
#[candid_method(update)]
fn set_node(args: SetNodeArgs<'static>) -> bool {
    assert!(OWNER == api::caller());
    assert!(PublicKey::parse_slice(args.pub_key, None).is_ok());
    let nodes = storage::get_mut::<NodePub<'static>>();
    if args.auth {
        nodes.insert(args.pub_key);
    } else {
        nodes.remove(args.pub_key);
    }
    return true;
}

I want to a function's

error[E0308]: mismatched types
  --> src/main.rs:65:1
   |
65 | #[update]
   | ^^^^^^^^^ one type is more general than the other
   |
   = note: expected trait `ArgumentDecoder<'a>`
              found trait `ArgumentDecoder<'_>`
   = note: this error originates in the attribute macro `update` (in Nightly builds, run with -Z macro-backtrace for more info)

I have a function annotated as follows:

#[ic_cdk_macros::init]
fn init() {
    unsafe {
        SOME_MAP = Some(HashMap::new());
    }
}

This code compiles and can be deployed to the local replica, however the global variable stays uninitialized. When I change ic_cdk_macros::init to ic_cdk_macros::update and call init explicitly, everything works as expected and the variable is initialized. Hence I conclude that the init macro has no effect for some reason.

$ dfx --version
dfx 0.7.0-beta.1

@nomeata, in your post on Zero-downtime upgrades of Internet Computer canisters, you said:

On Rust, you have to use the System API directly or wait for cdk-rs to provide this ability (patches welcome, happy to advise)

Please can you advise? 🙂

The StableReader always read the whole buffer and there is no check that we don't read out of bound bytes.

I have two aliases with the same type

pub type PortalNameStore = HashMap<String, u64>;
pub type PortalSlugStore = HashMap<String, u64>;

When grabbing it from storage it accesses the same object in memory

  let name_store = storage::get_mut::<stores::PortalNameStore>();
  let slug_store = storage::get_mut::<stores::PortalSlugStore>();

Somehow I got this far without noticing... since by chance everything else was unique.

Not an expert on Rust, but was thinking of changing it to:

  let name_store = storage::get_mut::<stores::PortalNameStore>("PortalNameStore");
  let slug_store = storage::get_mut::<stores::PortalSlugStore>("PortalSlugStore");

Is there a better way?

While trying to run proptest, just the simplest test run, I immediately get the runtime error: https://github.com/AltSysrq/proptest.

Seems there are a number of these basic functionalities that the platform or target could provide, time and randomness come to mind. Each time I run into these issues I have to figure out how to fix them in non-elegant ways, it would be nice for them to just work.

• There should be an explanation of why this is safe. If unsafe, it needs an explanation of how to use it safely, and it should be marked as unsafe at the interface level.
• It should also include an explanation of why the unsafe block is necessary.

I see this code:

    if err_code != 0 {
        let mut state = state.borrow_mut();
        state.result = Some(Err((
            RejectionCode::from(err_code),
            "Couldn't send message".to_string(),
        )));
    }

This confuses synchronous error codes as returned by invoke_call (currenly always 0 or 1) with the reject codes that come with, well, a reject message.

Furthermore, this conflation doesn’t allow the programmer to react differently to synchronous and asynchronous errors, which is very important (e.g. you can use api::call::msg_cycles_refunded only in a callback).

Otherwise it could be interpreted as 32-bits integers by the compiler and allocate too much buffer space.

storage can lead to memory corruption when a dangling reference is created.

Example from @roman-kashitsyn:

fn f() {
    let v = storage::get::<Vec<String>>();
    let v_0_ref = &v[0];
    g();
    h(v_0_ref); // dangling reference: g invalidated it
}
fn g() {
    let v = storage::get_mut::<Vec<String>>();
    v.push("hello".to_string());
    v.push("world".to_string());
}

The examples are configured to use dfx 0.6.15. When attempting to use dfx 0.7.1, the chess example fails with:

#     ERROR in /home/runner/work/cdk-rs/cdk-rs/examples/chess/src/chess_rs_assets/integration.tsx
#     ./src/chess_rs_assets/integration.tsx
#     [tsl] ERROR in /home/runner/work/cdk-rs/cdk-rs/examples/chess/src/chess_rs_assets/integration.tsx(4,8)
#           TS1192: Module '"/home/runner/work/cdk-rs/cdk-rs/examples/chess/.dfx/local/canisters/chess_rs/chess_rs"' has no default export.

I'm not seeing a way to configure a timeout for query calls in the Rust agent. It would be nice to configure this, if I'm missing how to do it I would appreciate an example. Thanks!

General description of the RUST CDK
Description and use case example for each macro.
(The detailed API is going to be extracted from the code using docs.rs as I understand it, but I think we still need some higher-level information to make sense of the reference information).

It would be great to have released versions of e.g. ic-cdk-optimizer. cargo installing it takes a bit of time.

At line

This leads to poor messages on the caller's side. I'd recommend calling ic_cdk::api::trap instead.

Maybe the idea was that too much details should NOT go to the caller; why not. But if so, then we need a good API for custom rejects, so that there is a way to send the caller good error messages. Today, I believe the only way to reject is through the guard attribute.

To make Rust-CDK block_on implementation compatible with the regular Rust block_on implementation it would be great if we could return values in our implementation of this function.

Rust CDK block_on implementation https://github.com/dfinity/rust-cdk/blob/01221cfd38df9ea85aa85fd7af56a0e87f3e8f6f/src/ic_cdk/src/lib.rs#L27

pub fn block_on<F: 'static + std::future::Future<Output = ()>>(future: F) -> ();

Rust Futures block_on implementation https://docs.rs/futures/0.3.5/futures/executor/fn.block_on.html

pub fn block_on<F: Future>(f: F) -> F::Output;

This is needed in my case to enable native execution testing for the canister code, but I believe it would also be useful for other users of the Rust CDK.

Currently, HashMap::Leaf only supports references.
Some clients want to be able to have a map of type RbTree<Key, Type> and convert values of Type to blobs on demand when the hash tree is constructed.
A simple solution is to store std::borrow::Cow<'a, [u8]> in the leaf.

Hello, I tried to reproduce examples from your guide for rust: https://sdk.dfinity.org/docs/rust-guide/multiply-dependency.html.
First of all this link isn't working https://sdk.dfinity.org/quickstart/quickstart.html#download-and-install
Then I made all steps that were in the instruction, changing paths to my local and after I successfully started the Internet Computer network and called in second terminal "dfx deploy" I received such an error :
'cargo build --target wasm32-unknown-unknown --package rust_deps --release'
thread 'main' panicked at 'Could not run custom tool.: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/dfx/src/lib/builders/custom.rs:181:18
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Could you please help me to understand what could I do wrong?
Examples with Motoko worked perfect for me, but in case with rust it can't find some directories.
upd. Same error for other examples

NNS dapp wants to persist an RbTree in stable memory and then recover it without recomputing any hashes (it runs out of cycles otherwise).
We could add a way of serializing the whole tree together with the intermediate hashes to handle this use-case.

When importing a candid file with the import macro then the generated code should looks like this (ic-cdk-macros-0.3.2\src\import.rs):

...
Ok(format!(
            r#"
            {{
                {call}(
                  ic_cdk::export::Principal::from_text("{principal}").unwrap() as ic_cdk::export::Principal,
                  "{name}",
                  {arguments}
                 )
                 .await
                 .unwrap()
            }}
        "#,
...

Here unwrap is called directly, so if the called canister traps then the calling canister traps as well.
Maybe the generated code shouldn't call unwrap() and the developer can decide what to do if the calling canister traps.

I already tried catch_unwind() (futures::FutureExt) but the caller canister still traps.

See https://forum.dfinity.org/t/rust-cdk-how-to-catch-panic-trap-when-calling-another-canister-which-traps/7886/

The CallFailedRecord does not insert data, but gets the value of Blanceces?
It looks like two stores are pointing to the same area

I run to start the rust chess example

dfx start --background --clean
dfx deploy

and get this error

0 info it worked if it ends with ok 1 verbose cli [ 1 verbose cli '/Users/gennaroschiano/.nvm/versions/node/v14.17.6/bin/node', 1 verbose cli '/Users/gennaroschiano/.nvm/versions/node/v14.17.6/bin/npm', 1 verbose cli 'run', 1 verbose cli 'build' 1 verbose cli ] 2 info using [email protected] 3 info using [email protected] 4 verbose run-script [ 'prebuild', 'build', 'postbuild' ] 5 info lifecycle [email protected]~prebuild: [email protected] 6 info lifecycle [email protected]~build: [email protected] 7 verbose lifecycle [email protected]~build: unsafe-perm in lifecycle true 8 verbose lifecycle [email protected]~build: PATH: /Users/gennaroschiano/.nvm/versions/node/v14.17.6/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/Users/gennaroschiano/Documents/GitHub/cdk-rs/examples/chess/node_modules/.bin:/Users/gennaroschiano/.opam/default/bin:/Users/gennaroschiano/Documents/Tezos/newtry/tezos/docs/ligo:/Users/gennaroschiano/.nvm/versions/node/v14.17.6/bin:/opt/homebrew/bin:/Library/Frameworks/Python.framework/Versions/3.9/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Users/gennaroschiano/.nix-profile/bin:/Users/gennaroschiano/.cargo/bin 9 verbose lifecycle [email protected]~build: CWD: /Users/gennaroschiano/Documents/GitHub/cdk-rs/examples/chess 10 silly lifecycle [email protected]~build: Args: [ '-c', 'webpack' ] 11 silly lifecycle [email protected]~build: Returned: code: 2 signal: null 12 info lifecycle [email protected]~build: Failed to exec build script 13 verbose stack Error: [email protected] build: webpack13 verbose stack Exit status 2 13 verbose stack at EventEmitter.<anonymous> (/Users/gennaroschiano/.nvm/versions/node/v14.17.6/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:332:16) 13 verbose stack at EventEmitter.emit (events.js:400:28) 13 verbose stack at ChildProcess.<anonymous> (/Users/gennaroschiano/.nvm/versions/node/v14.17.6/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14) 13 verbose stack at ChildProcess.emit (events.js:400:28) 13 verbose stack at maybeClose (internal/child_process.js:1055:16) 13 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:288:5) 14 verbose pkgid [email protected] 15 verbose cwd /Users/gennaroschiano/Documents/GitHub/cdk-rs/examples/chess 16 verbose Darwin 20.6.0 17 verbose argv "/Users/gennaroschiano/.nvm/versions/node/v14.17.6/bin/node" "/Users/gennaroschiano/.nvm/versions/node/v14.17.6/bin/npm" "run" "build" 18 verbose node v14.17.6 19 verbose npm v6.14.15 20 error code ELIFECYCLE 21 error errno 2 22 error [email protected] build:webpack 22 error Exit status 2 23 error Failed at the [email protected] build script. 23 error This is probably not a problem with npm. There is likely additional logging output above. 24 verbose exit [ 2, true ]

Can we please get a function in the Rust CDK for canister creation and installation.
https://docs.dfinity.systems/public/#ic-create_canister

The replica used in DFX already supports this functionality, we only need some interface functions

I believe the advantage of rust over motoko is there are a lot of rust packages available.
Can I use all the packages for rust? can I compile all rust to target web assembly?
Any limitation in using rust?

George Wu

The occurs on both ubuntu 20.04 as well as ubuntu 18.04 when using the default version of rust:

error: linking with cc failed: exit code: 1
|
= note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-Wl,--eh-frame-hdr" "-L" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.134v3536so0cjgde.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.15hbxgbzmet9tyz4.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.1c7z9l20g94jclcy.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.1ihpskp3xa1t6vtb.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.1jt2bfk4nn3mz87f.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.231vaqjds5342524.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.23rscwkopdizsa9f.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.27xrr47fxg5peguk.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.2na8770k3wic3igs.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.2yk0enma55ulg4yl.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.35yjyyqp4fsmgd60.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.3aq3u7wc4o8gesz.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.3doyqubeeja23j7t.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.3gyikqbwrxg8hub.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.3lnt1qukc3c4m36k.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.3pgzxmacjtfikr4r.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.3r0iayu568cy852l.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.3thkymiu73ok98du.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.3u95qootzwcrnbjn.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.3ukwnjz7axjv3on1.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.3ybnl29501kjax2h.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.46jq1ci424vghox1.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.4boducdqpayp0mpe.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.4m9kd3o2e5820mz1.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.4wrdotgw88hlej8w.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.4xmv06nb0lo2cxah.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.500qxl2xdqu58v2h.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.515e2d8mo6y1pbf8.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.54bv663js6y8rf6m.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.5em0ha7ozdvv6rbt.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.6nlehi359bm7183.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.fgl4txudlsag12i.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.h5jagct15t7lis1.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.u2yuvzg0i7ccz9b.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.wntr1bm570q65dn.rcgu.o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.xh0pok6ok8ksohm.rcgu.o" "-o" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libcounter_rs.so" "-Wl,--version-script=/tmp/rustcJaDgOc/list" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/counter_rs.oidqfh9vxb73be1.rcgu.o" "-Wl,--gc-sections" "-shared" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" "-L" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps" "-L" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libic_cdk-99277f4105de7461.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libwee_alloc-583d8bc66e627ea0.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/liblibc-eebcac3f5a162683.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libmemory_units-50e13edf57ad6aca.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libcfg_if-41deda4e4d6a4191.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libcandid-343cf291879fa013.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libhex-2584ac7ada2bfc2e.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libleb128-0f389615f9905d68.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libbyteorder-685b7428d2bcaad1.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/liblogos-bbcf45b522b04f9d.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libnum_bigint-82e2dd442358dfef.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libnum_integer-fcb61340f36cf451.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libnum_traits-502852900459fe1e.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libnum_enum-3141644efa3d1d47.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/liblalrpop_util-d051b022437f55fc.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libcodespan_reporting-362a64a784a8a53c.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libunicode_width-30213bb6556eed17.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libtermcolor-bbc8ceec8bb84b02.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libpretty-c39d69a3de0910e6.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libarrayvec-b9f8a1d5b55669af.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libtyped_arena-63d774b78eba5916.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libic_types-13d0a68442faa40c.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libcrc32fast-2f0f4c7e7322ba23.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libbase32-bfd838fb0ec39201.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libserde-fc799ee135e8abc8.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libthiserror-453efaeafd6b9dc0.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libsha2-5811d772b7ee7628.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libcpuid_bool-4f14ef72126f032d.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libcfg_if-c1b17704da0d8978.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libopaque_debug-027486154ff6624e.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libdigest-6dd22f2cf4a3b665.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libblock_buffer-c753cf27a3453ec9.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libgeneric_array-1566cfac260a195a.rlib" "/home/vagrant/cdk-rs/examples/counter/target/debug/deps/libtypenum-5800238ca839010a.rlib" "-Wl,--start-group" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-93cbfed54dd1bac8.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-db33fe383d9e671a.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-4afe0e223ea50f9d.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-76d88ad8c833f039.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-762cea37cccf8abe.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-8de1e75656157df8.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-76f54e5a49eca8e8.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-d7aed80bcad8813a.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-a3916e8afa60a160.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-eaacce9b176ef080.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-81e497cd060f0dda.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-949464f6d582f46f.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-1ffc094785c92121.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-f19c324859e53f08.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-0b82195f1020bf42.rlib" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-4f2339b0071e1016.rlib" "-Wl,--end-group" "/home/vagrant/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-774a5f30b27a1f9c.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-ldl" "-lutil"
= note: /usr/bin/ld:/tmp/rustcJaDgOc/list:4: syntax error in VERSION script
collect2: error: ld returned 1 exit status

Testing is an essential part of application writing, and Rust has a relatively mature testing framework.

I can envision that most if not all canister application writers will want to have their applications fully tested before deploying them to the IC.

We should provide an extensive set of testing examples, such as:

• unit testing of a single canister, before deploying to the IC
• unit testing of multiple canisters, before deploying to the IC
• integration and system testing, before and after deploying to the IC
• stress and end-to-end testing in dev and test environments on the IC

This issue documents one problem that we've observed while developing BigMap with the rust-cdk.

In that code we wrote, we're making put update calls from the index canister to the data bucket canisters. The put update call has two arguments fn put (key: Vec<u8>, value: Vec<u8>) - which is likely the source of problems.

Invoking the put function from the user works as expected, e.g. with the dfx canister call command - so all good so far.

However, when the put function is invoked from the index canister, argument parsing fails. By trial and error, I have found that when the index canister invokes data_canister.put(key, value), the data canister instead receives the arguments as fn put((key, value)), i.e., the arguments are not unpacked at the destination canister.

The following work-around works. I've added another method which is invoked from the index canister, and this method receives the argument tuple, unpacks it, and invokes the regular put function.

#[update]
fn put_from_index(key_value: (Key, Val)) -> bool {
    let (key, value) = key_value;
    put(key, value)
}

The sample code which demonstrates this is here: https://github.com/dfinity/bigmap-rs/blob/eefec72442898264ce6d7198b041bb9a64b4128c/src/bigmap_data.rs#L72

I followed Hello, World! Rust CDK Quick Start and ran into some trouble at the dfx deploy step. I'm using dfx version 0.7.0-beta.8.

$ dfx deploy
Deploying all canisters.
All canisters have already been created.
Building canisters...
Executing 'cargo build --target wasm32-unknown-unknown --package rust_hello --release'
    Finished release [optimized] target(s) in 0.15s
The post-build step failed for canister 'rrkah-fqaaa-aaaaa-aaaaq-cai' with an embedded error: No such file or directory (os error 2)

Since the new Rust nightly release, the v0.4.0 of the num_bigint package is broken which candid is depended on, and since this crate is also depended on the Candid crate, this also fails to build on nightly.

I have already open a PR on the Candid repository to migrate to v0.4.2 of the num_bigint to fix the build errors, until then ic_cdk remains broken too.

Related links:
dfinity/candid#274
rust-lang/rust#88581
rust-num/num-bigint#219

Forum post: https://forum.dfinity.org/t/condvar-wait-not-supported/9052

I'm trying to execute cross-canister calls from within a function that I cannot make async. I am using the futures crate to do this. futures::executor::block_on works just fine if I call my own async functions, but when I try to call ic_cdk::api::call::call I get this error:

[Canister rrkah-fqaaa-aaaaa-aaaaq-cai] Panicked at 'condvar wait not supported', library/std/src/sys/wasm/../unsupported/condvar.rs:23:9

Here's an example of the call I am trying to make (this is within a function that cannot be made async):

let string = futures::executor::block_on(async {
    let call_result: Result<(String,), _> = ic_cdk::api::call::call(
        ic_cdk::export::Principal::from_text("ryjl3-tyaaa-aaaaa-aaaba-cai").unwrap(),
        "testString",
        ()
    ).await;

    return call_result.unwrap().0;
});

I've narrowed things down to...well, I really think there's an issue in the ic-cdk futures implementation somehow. I don't yet understand Rust futures super well, but my own async functions work just fine, so I assume there is an issue with the futures that ic-cdk functions are using.