Embedding wasm - dfx 0.17.0 crashing where previous version works

Developers
28

I finally managed to reproduce the error locally. So I believe I found the real cause of the issue.

Bug

In ic-utils crate, there was a bug in InstallBuilder::call_and_wait_with_progress(). It couldn’t handle the case of non-empty chunk store.

dfx v0.16.0 to v0.19.0 depended on this buggy ic-utils when install wasm larger than 1.85 MiB .

So for the canister installation failures discussed in this forum thread, it’s likely that the chunk store was not empty before the installation.

Fix

The merged agent-rs PR and sdk PR fixed the issue. I verified that the dfx built from sdk master branch can handle such cases properly.

EDITED:

I opened a PR which adds a test to make sure that we fixed the real issue.
I reproduced the error in CI by downgrading agent-rs to a previous buggy version.

The upcoming dfx release next week will certainly have the fix.

Before that, there is an easy remedy to unblock your current work.

Check

You can check if your canister’s chunk store is empty by this command (replace the canister id with yours):

dfx canister call --ic aaaaa-aa stored_chunks '(record { canister_id = principal "bkyz2-fmaaa-aaaaa-qaaaq-cai" })'

The result will be like:

(
  vec {
    record {
      1_158_164_430 = blob "\96\a2\96\d2\24\f2\85\c6\7b\ee\93\c3\0f\8a\30\91\57\f0\da\a3\5d\c5\b8\7e\41\0b\78\63\0a\09\cf\c7";
    };
  },
)

A non-empty vec means that the chunk store is non-empty.

Remedy

If the check above turns out to be positive, it is easy to fix it.

You only need to execute this command (replace the canister id with yours):

dfx canister call --ic aaaaa-aa clear_chunk_store '(record { canister_id = principal "bkyz2-fmaaa-aaaaa-qaaaq-cai" })'

Then you should be able to install your canister.

Thanks for all your patience!

3 Likes