I ran into this problem just now. It didn’t become a show-stopper in the end but probably reveal something buggy of dfx or the network. It might be good if someone from the SDK team can look into it. Thanks!
My site went down because of insufficient cycles balance. So I tried to top up cycles balance for the canister hbc6w-gqaaa-aaaag-aagdq-cai. The repo was originally deployed on dfx 0.13.1 . Terminal gave me a warning when I tried to run dfx canister --network=ic status hbc6w-gqaaa-aaaag-aagdq-cai as my Mac was already upgraded to dfx 0.14.1. I removed the line for the version number in dfx.json and run this again,
dfx canister --network=ic status hbc6w-gqaaa-aaaag-aagdq-cai
The command just hung there, with no output message.
I tried to run exactly the same canister command in another dfx project for a different canister and it produced the intended status output,
dfx canister --network=ic status bp6lc-ziaaa-aaaag-abqyq-cai
Canister status call result for bp6lc-ziaaa-aaaag-abqyq-cai.
Status: Running
Controllers: iyr2m-aiaaa-aaaag-aaa2q-cai lwhis-d5gpt-zbgse-qdivc-jmt5p-smhdq-h2dbt-vbh7x-h4g4d-tyg2x-zqe
Memory allocation: 0
Compute allocation: 0
Freezing threshold: 2_592_000
Memory Size: Nat(6403290)
Balance: 283_678_685_782 Cycles
Module hash: 0x651425d92d3796ddae581191452e0e87484eeff4ff6352fe9a59c7e1f97a2310
The only difference between these two dfx projects (other than different static contents etc) that I can recall is that the dfx project for canister hbc6w was deployed with dfx 0.13.1 and the dfx project for canister bp6lc was deployed with dfx 0.14.1. The first one could not successfully execute dfx canister command while the second one had no problem.
Puzzled, I went ahead to top up 20 billion cycles, even though I had no idea what was the remaining balance and how much I should top up - which is supposed to come from the output message from dfx canister status.
Surprisingly, it actually worked.
dfx canister --network=ic deposit-cycles 20000000000 hbc6w-gqaaa-aaaag-aagdq-cai
Depositing 20000000000 cycles onto hbc6w-gqaaa-aaaag-aagdq-cai
Deposited 20000000000 cycles, updated balance: 63_753_354_219 cycles
I tried to run this again, but it still just hung there with no output,
dfx canister --network ic status hbc6w-gqaaa-aaaag-aagdq-cai
Running out of options, I topped up additional 100 billion cycles,
dfx canister --network=ic deposit-cycles 100000000000 hbc6w-gqaaa-aaaag-aagdq-cai
Depositing 100000000000 cycles onto hbc6w-gqaaa-aaaag-aagdq-cai
Deposited 100000000000 cycles, updated balance: 163_747_472_467 cycles
And finally dfx canister status worked,
dfx canister --network ic status hbc6w-gqaaa-aaaag-aagdq-cai
Canister status call result for hbc6w-gqaaa-aaaag-aagdq-cai.
Status: Running
Controllers: iyr2m-aiaaa-aaaag-aaa2q-cai lwhis-d5gpt-zbgse-qdivc-jmt5p-smhdq-h2dbt-vbh7x-h4g4d-tyg2x-zqe yxaiy-ge4x3-xwdqi-r5kim-46lbl-52ulu-46sx7-hzhev-mrsqr-mvygl-eae
Memory allocation: 0
Compute allocation: 0
Freezing threshold: 2_592_000
Memory Size: Nat(276268060)
Balance: 163_745_829_703 Cycles
Module hash: 0x98863747bb8b1366ae5e3c5721bfe08ce6b7480fe4c3864d4fec3d9827255480
The site is back on running, but the question remains, why didn’t dfx canister status work before I had to top up the cycles? It’s supposed to tell me the freezing threshold and remaining balance, so that I can make a decision on how much cycles to top up for. I sort of flew blind (by topping up cycles at random numbers) and fixed it, but that’s probably not the ideal intended developer experience.
