install with custom build looking in the wrong directory

[gabrielnic]

Hi so I'm trying to install with a custom build but upon doing some checks it's not working as intended.

With the release of 0.12.1 I wanted to try custom builds because we really need gzip. This is the dfx.json: https://github.com/gabrielnic/motoko-test/blob/main/dfx.json This is the custom build script: https://github.com/gabrielnic/motoko-test/blob/main/compress.sh

It simply compiles and generate the files, shrink and then gzip.

The issue is that even tho I'm creating the wasm file in declarations and the dfx idl and wasm are pointing in there, on install it's still looking in the .dfx folder

On install I get this error gabriel@DESKTOP-8G906R5:~/projects/motoko-test$ dfx canister install --all Creating UI canister on the local network. The UI canister on the "local" network is "ryjl3-tyaaa-aaaaa-aaaba-cai" Error: Failed to install wasm module to canister 'test'. Caused by: Failed to install wasm module to canister 'test'. Failed to read /home/gabriel/projects/motoko-test/.dfx/local/canisters/test/test.wasm. No such file or directory (os error 2)

Also on dfx build even tho build points in declarations folder for some reason it creates the files in declarations as expected but it also creates the files in .dfx/local/canisters/test

This is the reason why install worked in the first place in small projects but not on our main one as I'm trying to find out here as well: https://forum.dfinity.org/t/dfx-build-vs-custom-build-and-post-build/16838/8

The expected behaviour is to create the files as instructed in dfx.json which is working but without creating them in the .dfx folder and then install look in the same folder and not just in .dfx

[sesi200]

Thank you for the bug report, @gabrielnic. I can reproduce your issue. The bug will be tracked internally under SDK-872.

Steps to reproduce:

• clone repo linked above
• dfx start --clean --background
• dfx canister create --all
• dfx canister install --all

Noteworthy:

• Bug does not occur if either dfx build or dfx deploy are used because these commands copy the wasm over to the right location in .dfx

Workaround:

• dfx build <canister>, followed by dfx canister install <canister> or using dfx deploy <canister> both work.

[gabrielnic]

Thank you for this.

Sorry, I forgot to put the steps to reproduce this.

I didn't realised the wasm file inside the .dfx folder is the same size as the gzipped one.

Also until your fix is released for this error The post-build step failed for canister 'rkp4c-7iaaa-aaaaa-aaaca-cai' (main) with an embedded error: No such file or directory (os error 2) I realised I can just copy the gzip in the .dfx and just rename like this p src/declarations/test/test.wasm.gz .dfx/local/canisters/test/test.wasm and it will work.

Also I can confirm the workaround works, so thank you for this.

Just to piggyback on this thread I noticed something else:

If I run dfx start in one folder and then navigate to another folder and I try to run a dfx command I get this

gabriel@DESKTOP-8G906R5:~/projects/motoko-test$ dfx ping Error: Failed while waiting for agent status. Caused by: Failed while waiting for agent status. An error happened during communication with the replica: error sending request for url (http://127.0.0.1:4943/api/v2/status): error trying to connect: tcp connect error: Connection refused (os error 111))

but where dfx is run it works gabriel@DESKTOP-8G906R5:~/projects/dragginz$ dfx ping { "ic_api_version": "0.18.0" "impl_hash": "a3fc4822c2b6bcbed3724b893accb7ce8f30349e1b2c3f3b35d0169a9c50a7c1" "impl_version": "0.8.0" "replica_health_status": "healthy" "root_key": [48, 129, 130, 48, 29, 6, 13, 43, 6, 1, 4, 1, 130, 220, 124, 5, 3, 1, 2, 1, 6, 12, 43, 6, 1, 4, 1, 130, 220, 124, 5, 3, 2, 1, 3, 97, 0, 178, 150, 229, 107, 95, 17, 27, 116, 203, 183, 176, 2, 142, 93, 93, 91, 42, 26, 250, 120, 92, 148, 68, 243, 169, 120, 222, 62, 39, 90, 222, 14, 229, 69, 216, 166, 73, 82, 119, 75, 64, 252, 191, 161, 64, 255, 109, 93, 4, 124, 45, 75, 80, 200, 44, 166, 160, 192, 90, 149, 107, 2, 62, 175, 133, 179, 76, 135, 200, 53, 91, 226, 52, 215, 113, 220, 79, 219, 121, 51, 98, 78, 19, 137, 45, 120, 170, 215, 238, 207, 21, 14, 91, 101, 214, 233] }

Based on this release note I'm guessing that's a bug as well https://internetcomputer.org/docs/current/developer-docs/updates/release-notes/#feat-system-wide-dfx-start

[sesi200]

If I run dfx start in one folder and then navigate to another folder

Just to double-check: The dfx project you do dfx start in, does that dfx.json contain a network descriptor? (something in the "networks" key) If yes, then you don't run the system-wide dfx - you run a project-specific network - and what you observe is the intended behaviour

[gabrielnic]

yup one of them had a network config in the dfx.json. Ok I didn't know that even if you that in dfx json even tho it's pointing to 4943 won't work. Good to know, thanks