That’s absolutely awesome news! Thanks @bjoern
Presumably licensing won’t make this use case infeasible (i.e. dev licences for testing/verification purposes), given that the intention is for Utopia to be a commercial enterprise-grade product.
I’m super excited about Utopia in general. Big fan!
Hello everyone, dfx 0.26.0-beta.2 is available for testing. You can read the release notes here.
To switch to the beta release, use dfxvm default 0.26.0-beta.2.
The main improvement over 0.26.0-beta.1 is with dfx creating a new wallet if the settings change. This makes it simpler to toggle between pocket-ic and the local replica, avoiding some of the issues our early testers ran into (thanks again for reporting the errors)
Migrating from 0.24.0 to 0.26.0 and am getting this bug in with PicJS when trying to create a canister via another canister’s API. The wasm of the canister that I’m trying to create was built with the dfx generate command. The wasm is being pulled from .dfx/local/canisters/<canister_name>/<canister_name>.wasm.gz
Error: Error from Canister 7uieb-cx777-77776-qaaaq-cai: Canister's Wasm module is not valid: Wasm module has an invalid import section. Module imports function 'subnet_self_copy' from 'ic0' that is not exported by the runtime..
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.
Just checked and this issue doesn’t appear with dfx 0.25.1
I ran into this issue mentioned above when using PicJS (PocketIC).
I’ve pulled in the 0.26.0 nns state according to commit f6f5e0927d14886e4bd67f776ee889f31cec2364 from the ic repo (the commit that 0.26.0 is built off of).
The error occurs during my pic (pocketIC) tests. When I try to call an endpoint on my canister that creates a canister through it, with this code:
const statusCheckerResult = await cycleOps.actor.createStatusChecker();
if ("err" in statusCheckerResult) {
throw new Error(
`Status checker creation failed. Error: ${statusCheckerResult.err}`
);
}
I receive this error:
Status checker creation failed. Error: Error from Canister 7uieb-cx777-77776-qaaaq-cai: Canister's Wasm module is not valid: Wasm module has an invalid import section. Module imports function 'subnet_self_copy' from 'ic0' that is not exported by the runtime..
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.
It looks like It looks like subnet_self_copy was added here feat(EXC-1847): Support for `ic0.subnet_self()` (#3637) · dfinity/ic@f0058db · GitHub
Is it possible that some of this didn’t make it into PocketIC/PicJS?
PocketIC shipped with dfx is indeed built at commit f6f5e0927d14886e4bd67f776ee889f31cec2364 which includes the ic0.subnet_self_size and ic0.subnet_self_copy system API (you can confirm that by deploying your canister via dfx instead of PicJS to a PocketIC instance created via dfx start).
I’m not sure about PicJS: could you please comment on that, @NathanosDev ?
dfx 0.26.0 has been promoted, see: DFX 0.26.0 has been promoted!
Was this issue fixed by using the @dfinity/pic package? That library has the latest pocketic which matches the one used by DFX 0.26.0.
Yes, this specific issue was fixed by the latest @dfinity/pic package! Thanks for following up.
I also encountered this issue and don’t know how to solve it.
Canister be2us-64aaa-aaaaa-qaabq-cai not found
Canister be2us-64aaa-aaaaa-qaabq-cai does not belong to any subnet
tl;dr I’d expect that using the --clean option should fix the issue.
not work for me😭
dfx start --clean
Running dfx start for version 0.26.1
Using shared network 'local' defined in /Users/zensh/.config/dfx/networks.json
Replica API running on 127.0.0.1:4943. You must open a new terminal to continue developing. If you'd prefer to stop, quit with 'Ctrl-C'.
dfx canister create --all
Error: Failed to create canister 'anda-cloud2-backend'.
Caused by: Failed to construct wallet canister caller
Caused by: The replica returned an HTTP Error: Http Error: status 400 Bad Request, content type "text/plain", content: Canister be2us-64aaa-aaaaa-qaabq-cai does not belong to any subnet.
I have fixed it.
Update networks.json from:
{
"local": {
"bind": "localhost:4943",
"type": "persistent",
"replica": {
"subnet_type": "application"
}
}
}
to:
{
"local": {
"bind": "localhost:4943",
"type": "ephemeral",
"replica": {
"subnet_type": "application"
}
}
}
@mraszyk @raymondk
I’m facing a serious issue: Running dfx canister create repeatedly causes the DFX runtime to crash, and the issue is reproducible.
Reproduction steps:
dfx canister create --specified-id rdmx6-jaaaa-aaaaa-aaadq-cai internet_identity
dfx canister create --specified-id ryjl3-tyaaa-aaaaa-aaaba-cai icp_ledger_canister
dfx canister create --specified-id druyg-tyaaa-aaaaq-aactq-cai icrc1_ledger_canister
dfx canister create --specified-id c63a7-6yaaa-aaaap-ab3gq-cai ic_panda_frontend
dfx canister create --specified-id a7cug-2qaaa-aaaap-ab3la-cai ic_panda_luckypool
dfx canister create --specified-id nscli-qiaaa-aaaaj-qa4pa-cai ic_message
dfx canister create --specified-id nvdn4-5qaaa-aaaaj-qa4pq-cai ic_message_channel
dfx canister create --specified-id ijyxz-wyaaa-aaaaj-qa4qa-cai ic_message_profile
dfx canister create --specified-id 2fvu6-tqaaa-aaaap-akksa-cai ic_message_frontend
dfx canister create --specified-id n3bau-gaaaa-aaaaj-qa4oq-cai ic_cose_canister
dfx canister create --specified-id 5szpn-tiaaa-aaaaj-qncoq-cai ic_oss_cluster
dfx canister create --specified-id 532er-faaaa-aaaaj-qncpa-cai ic_oss_bucket
dfx canister create --specified-id qc6wh-6yaaa-aaaap-anuza-cai dmsg_index_canister
dfx canister create --specified-id ocqzv-tyaaa-aaaar-qal4a-cai dmsg_ledger_canister
dfx canister create --specified-id ql553-iqaaa-aaaap-anuyq-cai ic_dmsg_minter
dfx canister create --specified-id 2rgax-kyaaa-aaaap-anvba-cai ic_name_identity
Error message:
➜ ~ dfx start --clean
Running dfx start for version 0.26.1
Using shared network 'local' defined in /Users/zensh/.config/dfx/networks.json
Replica API running on 127.0.0.1:4943. You must open a new terminal to continue developing. If you'd prefer to stop, quit with 'Ctrl-C'.
^CAll local network processes stopped
➜ ~ dfx start
Running dfx start for version 0.26.1
Using shared network 'local' defined in /Users/zensh/.config/dfx/networks.json
Replica API running on 127.0.0.1:4943. You must open a new terminal to continue developing. If you'd prefer to stop, quit with 'Ctrl-C'.
thread 'tokio-runtime-worker' panicked at rs/pocket_ic_server/src/pocket_ic.rs:716:63:
called `Result::unwrap()` on an `Err` value: RoutingTableNotDisjoint("Routing table cannot insert an overlapping range: CanisterIdRange { start: CanisterId(lxzze-o7777-77777-aaaaa-cai), end: CanisterId(x47dp-5x777-77777-p777q-cai) }")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'tokio-runtime-worker' panicked at rs/state_machine_tests/src/lib.rs:2539:13:
Critical error mr_empty_canister_allocation_range occurred.
stack backtrace:
0: 0x10394d6a6 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h27292a0ce9b80dea
1: 0x103974493 - core::fmt::write::hb0572c5b638e8f85
2: 0x103948ad2 - std::io::Write::write_fmt::h96d024dacceb3f49
3: 0x10394d4e2 - std::sys::backtrace::BacktraceLock::print::h10e7f6d0bb9e5f3a
4: 0x10394ebc1 - std::panicking::default_hook::{{closure}}::h5066d120a206f26b
5: 0x10394e9fb - std::panicking::default_hook::hee7aaab096d3b5b1
6: 0x10394f402 - std::panicking::rust_panic_with_hook::hf08aa6bfdce8d020
7: 0x10394f088 - std::panicking::begin_panic_handler::{{closure}}::h4ee0c318fbff139c
8: 0x10394db89 - std::sys::backtrace::__rust_end_short_backtrace::h34aa566de9a39ee3
9: 0x10394eccc - _rust_begin_unwind
10: 0x103a3cc3f - core::panicking::panic_fmt::hff6bcefe3b08b0dc
11: 0x1014c8e9b - ic_state_machine_tests::StateMachine::check_critical_errors::ha6784703cb141f96
12: 0x1014c99ce - ic_state_machine_tests::StateMachine::execute_payload::hd9972629185adec1
13: 0x1014c8c33 - ic_state_machine_tests::StateMachine::tick::hde57fb3712767f2a
14: 0x1014ca801 - ic_state_machine_tests::StateMachine::checkpointed_tick::hed061de018ec38d1
15: 0x101237bda - <pocket_ic_server::pocket_ic::PocketIc as core::ops::drop::Drop>::drop::h08d145f30b0329ed
16: 0x1010e02b3 - core::ptr::drop_in_place<pocket_ic_server::pocket_ic::PocketIc>::h637c3968ebb8befd
17: 0x1010c1b54 - <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll::h51f67ff0bd7ec9bc
18: 0x100e80648 - tokio::runtime::task::core::Core<T,S>::poll::hb8c28f3727b4e617
19: 0x100e3a031 - tokio::runtime::task::harness::Harness<T,S>::poll::hbff8454267a20f32
20: 0x1038af34c - tokio::runtime::blocking::pool::Inner::run::h44de3148697b69a3
21: 0x1038b3eb9 - std::sys::backtrace::__rust_begin_short_backtrace::h4f6b3ec5d46c0ba0
22: 0x103899795 - core::ops::function::FnOnce::call_once{{vtable.shim}}::ha4185cba748c1f0e
23: 0x1039550bb - std::sys::pal::unix::thread::Thread::new::thread_start::hcfbe36d5799581a6
24: 0x7ff80d93cdf1 - __pthread_start
thread 'tokio-runtime-worker' panicked at core/src/panicking.rs:231:5:
panic in a destructor during cleanup
thread caused non-unwinding panic. aborting.
dfx start --replica works for me
Thanks a lot for the bug report!
I could reproduce the issue which is caused by creating canisters with a specified id (--specified-id) in a local test environment started by dfx start (i.e., without using the --clean option).
My recommendation in the short term (before the issue is resolved) is to only create canisters with --specified-id in a local test environment started by dfx start --clean and do not create any canisters with --specified-id after resuming that local test environment later (by running dfx start). Is that workflow acceptable for now?
I’m currently rebuilding my test environment using dfx start --replica and setting up test data.
Additionally, I strongly dislike --clean—accumulated test data is crucial, as multiple canisters in dMsg have complex data dependencies.
It is fine to not use --clean, it is just important to not create any new canisters using --specified-id at that point anymore.
The issue has been fixed in PocketIC (PR): once the PocketIC version in dfx is updated, the issue will be resolved.