Hey @cwb2819259, sorry for this bad error message. Are you sure the canister_id field you passed in was for an existing canister? I’d expect this error to show up if you try to use a canister_id that doesn’t exist.
We’ve also merged a change that fixes the error message here, so after the current release the error should indicate that the subnet for the requested canister couldn’t be found.
Ok, then I’m not sure exactly what’s going wrong. Can you send some steps to reproduce this (the sequence of dfx commands and canister source)? Also what does the error look like now when you run try it on mainnet?
Has anyone managed to reproduce/fix this? Here is a minimally reproducible snippet which shows the canister ID should be correct, unless I’m missing something? This code produces the same error described above: Err((DestinationInvalid, "No route to canister aaaaa-aa"))
That error was produced locally on dfx (I’m using latest - 0.11.2).
I’ve just deployed that same snippet to mainnet , and it seems in this case, related to a Candid error. Though I’m still trying to decode what it’s saying
(DestinationInvalid, "Unable to route management canister request install_code: CandidError(Custom(Fail to decode argument 0 from table0 to record {\n arg : vec nat8;\n wasm_module : vec nat8;\n mode : variant { reinstall; upgrade; install };\n canister_id : principal;\n query_allocation : opt nat;\n memory_allocation : opt nat;\n compute_allocation : opt nat;\n}\n\nCaused by:\n 0: input: 4449444c036c04d6fca70201a79fc97e01e3a683c30402b3c4b1f204686d7b6b03fcb88b84037ffbf9afd7057fa8fbd5fe0a7f0100_00080061736d0100000001010a00000000015006110101\n table: type table0 = record {\n 4_849_238 : table1;\n 265_441_191 : table1;\n 1_214_305_123 : table2;\n 1_313_628_723 : principal;\n }\n type table1 = vec nat8\n type table2 = variant { 813_882_492; 1_525_415_163; 2_950_004_136 }\n wire_type: table0, expect_type: record {\n arg : vec nat8;\n wasm_module : vec nat8;\n mode : variant { reinstall; upgrade; install };\n canister_id : principal;\n query_allocation : opt nat;\n memory_allocation : opt nat;\n compute_allocation : opt nat;\n }\n 1: table0 is not a subtype of record {\n arg : vec nat8;\n wasm_module : vec nat8;\n mode : variant { reinstall; upgrade; install };\n canister_id : principal;\n query_allocation : opt nat;\n memory_allocation : opt nat;\n compute_allocation : opt nat;\n }\n 2: Record field mode: table2 is not a subtype of variant { reinstall; upgrade; install }\n 3: Variant field 813_882_492 not found in the expected type))")',
After inspecting this error, it looked like the issue was coming from the CanisterInstallMode::Install variant (which I was importing from management_canister::main).
I’ve just rewritten this type and it now works , with this code:
This could just be the same problem you were seeing in dfx. As mentioned earlier in the thread, the “No route to canister aaaaa-aa” message wasn’t the real error and we’ve rolled out changes to mainnet to show the real error. But it looks like those changes haven’t hit dfx yet.
Which version of the ic_cdk rust library do you have in your Cargo.lock? I just tried to reproduce the error with your first snippet and it succeeded. Here’s exactly what I did:
dfx new create_canister_error --type rust --no-frontend
cd test
# copy your first snippet into `src/create_canister_error_backend/src/lib.rs` and add required imports
# Add `"install": () -> ();` to `create_canister_error_backend.did`
dfx start --background
dfx deploy
dfx canister call create_canister_error_backend install '()'