Dfx deploy hangs

Developers
1

Hi,

After getting the hello tutorial app running on my laptop, I created an identity dfxter and added some cycles.

dfx wallet --network ic balance
Please enter the passphrase for your identity: [hidden]
Decryption complete.
13.125 TC (trillion cycles).

Then I tried to deploy the dapp but dfx_deploy hung after printing building frontend…
dfx deploy --network ic
Please enter the passphrase for your identity: [hidden]
Decryption complete.
Deploying all canisters.
Creating canisters…
Creating canister hello_frontend…
hello_frontend canister created on network ic with canister id: oukwd-paaaa-aaaap-qa6ca-cai
Building canisters…
Shrink WASM module size.
Building frontend…

I waited several minutes. cpu was mostly pegged with dfx running at 100% so I gave up and hit cntl-c

Tried dfx wallet again to check my balance:
dfx wallet --network ic balance
Please enter the passphrase for your identity: [hidden]
Decryption complete.
10.025 TC (trillion cycles).

Any insight or suggestions?

2

So, I guess I’ve got a container on chain that contains cycles but no WASM.

3

Try

dfx canister --network ic stop <your-sort-of-deployed-canister-id>

then (even if stop fails)

dfx canister --network ic delete <your-sort-of-deployed-canister-id>

then check your balance again. delete should withdraw them back to your wallet automatically.

4

Hi Blabagastered, thanks for pointing me in the right direction.

the stop command seemed to work happily, but delete ultimately failed as it attempted to transfer cycles.

However, after a series of stop and delete commands I eventually decided to delete with --no-withdrawal --all . Which at least got rid if the peskily persistent canister (along with the associated cycles).

dfx canister delete --no-withdrawal --all --network ic
Please enter the passphrase for your identity: [hidden]
Decryption complete.
Deleting code for canister hello_backend, with canister_id obnho-oiaaa-aaaap-qa6bq-cai
Deleting code for canister hello_frontend, with canister_id oukwd-paaaa-aaaap-qa6ca-cai

1 Like
5

Glad it somewhat helped.

By the way, if you want to try deploying again without risking too many cycles, you can use this flag:

dfx deploy --network=ic --with-cycles 100000000000

Not sure if you can go as low as 100B cycles as quoted there (never tried, only heard things that make me think it might), but it should definitely work with 1T.

6

Got it, thanks.

In case anyone else finds themselves with a similar difficulty, I’ll add that the first time that I tried
dfx canister delete --no-withdrawal --all --network ic

I received an error and advice that I needed to stop the canister associated with hello_backend before it could be deleted. I’d never gotten an address for that canister printed to my screen before, so I was unaware of it. After I stopped it, the dfx delete… shown above worked. HOWEVER, I suspect that I needn’t have used the --no-withdrawal flag if I had stopped that canister first.

7

I reproduced the problem, killed the canister deploy because it hung again, but this time stopped both of the canisters (frontend and backend) before attempting to use dfx delete without the --no-withdrawal flag. Still failed so I can only delete the canister using the --no-withdrawal flag

8

That’s weird and I’ve not come across it. Let’s hope someone else knows what’s up. I wonder if there was some sort of glitch while setting up your secure identity, or even a bug in that process.

9

Peculiar, yes. I’m going to start from scratch and see if I can get to work with my default identity, then maybe I can isolate the problem.

1 Like
10

I restarted the hello tutorial from scratch and had no problem deploying all canisters using the default identity.

One thing that I noted while repeating the exercise was that I had failed to issue a dfx stop in the local environment after hitting cntl-c to stop the dfx start process. Could that possibly have caused the problem that I experienced attempting to deploy on chain?

11

Your issue is most likely this one: Dfx deploy locally with a new Dfx identity - #24 by Severin

I’d personally put a soft limit at 200B cycles. Canister creation itself costs 100B cycles, so if you deploy with 100B the canister will have 0 left over and your deployment fails in a very newbie-unfriendly way. If the canister is already created, then the --with-cycles flag has no effects

1 Like