I see two ways to resolve this. Either you move to canister type custom and point it to the gzipped wasm or you point your build script at the gzipped wasm (using --wasm target/wasm32-unknown-unknown/release/<canister>.wasm.gz).
I haven’t double-checked but I would assume dfx copies the wasm into a local cache inside of .dfx. It does that to do some more transformations like baking the .did file into the right metadata section so it shows up in chain explorers properly
When I install without the --wasm flag, the argument values are properly passed to the canister init function. However, when I use the --wasm flag, these values are not being passed into the canister’s init function. Something I am missing?
Also, I found that when --wasm is specified, Candid UI isn’t installed as well. Is this intended?
Kinda stuck with this. Appreciate any help you can provide
If you use --wasm then the argument parsing is indeed different from the one used otherwise (see last arg to the function). But I don’t understand why this would turn out so differently. If parsing fails, it would complain either way
I’m not sure. Reading the code, I get the impression that --wasm is meant for a very manual process, but I’m not sure that it should skip Candid UI entirely. For now I can offer as a workaround that you install any random canister without the --wasm flag because that will then automatically install Candid UI.
A reproduction would be perfect. If you want an ugly workaround, you could copy the wasm to the place where dfx would expect it to be and hope that it works. It would expect the wasm to be at .dfx/<network name>/canisters/<canister name>/<canister name>.wasm
Thank you very much for the repro! I get the same result, and don’t like it
I filed the bug (note to future self: internal ticket) and hope we soon get around to fixing it.
Do you need help to find a workaround for now? I think if you put the gzipped wasm to .dfx/local/canisters/backend/backend.wasm (just strip the .gz extension) then dfx canister installshould pick it up even without the–wasm` flag
--wasm is used to interface with foreign canisters; it neither requires nor integrates with dfx.json. This means that it does not know about the full candid interface, which interacts badly with a bug in candid involving merging unknown variants into a common type. (The data is actually there, it’s just being serialized with the wrong variant, and HashMap is pruning the duplicated key.) In general you should not be using --wasm as part of a general deployment strategy.