Cannot delete canisters anymore

Has anyone else experiencing issues recently trying to delete canisters?

I am not able to delete canister anymore, I get following error when I try to do so:

Error: Call was rejected:
Request ID: 6c6d2f761b741…9866dcd61e900cb
Reject code: 4
Reject text: IC0501: Canister jjmme-aqaaa-aaaai-ab5ya-cai is out of cycles: requested 893853709998 cycles but the available balance is 893857809998 cycles and the freezing threshold 2057103111 cycles

I did not change my code nor faced the error previously.

Not later than a week ago I even used the function multiple times to determine what are the minimal cycles to retain upon deleting a canister (see post). Therefore quite surprise it does not work anymore out of the blue.

I also get the error when I create a fresh canister (create → do nothing else → delete → error).

So anyone having issues? Any idea what’s the issue?

My delete function:

let deckBucket = actor(Principal.toText(canisterId)): actor { transferCycles: () -> async () };

await deckBucket.transferCycles();

await ic.stop_canister({ canister_id = canisterId });

await ic.delete_canister({ canister_id = canisterId });

The transfer cycles:

public func transferCycles(caller: Principal): async () {
            let balance: Nat = Cycles.balance();

            let cycles: Nat = balance - 4_100_000;

            if (cycles > 0) {
                await ic.deposit_cycles({ canister_id = caller });
1 Like

Alright I can reproduce the exact same issue on mainnet with a sample repo.

To deploy my canister on mainnet, I create a canister in nns-dapp, link my controller, add a canister_ids.json to the project and then deploy with the command dfx deploy --network=ic --no-wallet

Can it be the root cause of the problem or there is indeed an issue elsewhere?

Note: it works just fine on the local simulated network - it does not on mainnet

1 Like

Thanks for the report and repro!

Can you confirm that the version that worked recently and the failing version were compiled with the same moc or dfx version? That’s to rule out a bug in Motoko.

I’ve also raised the issue internally with the execution team in case they can explain it.

1 Like

Thanks Claudio.

Cannot be 100% sure but it might have stopped to work after I upgraded dfx indeed. I used to used v0.8.4 if I remember correctly.

An internal user reports:

IIRC, I once ran into a similar error when I didn’t upgrade my wallet after updating dfx.
I just created an account on the forum and can’t reply yet. Can you them if they have upgraded their wallet? dfx wallet upgrade

❯ dfx wallet --network ic upgrade
Error: Could not find wallet for “default” on “ic” network.

I create the canister in nns-dapp, link my controller and then deploy with --no-wallet therefore I guess there isn’t a wallet locally?

That’s me.

--no-wallet (which isn’t needed after the latest dfx upgrade anymore, it’s implicit now) means that the wallet is not used to sign/send/? the commands. Your identity’s principal is the origin of your request.
It is still necessary to have a wallet to withdraw the cycles (unless you want to use --no-withdrawal and lose the cycles).
According to the error message you get, it looks like you don’t have a cycles wallet configured with your identity ‘default’. If you already have a cycles wallet, you can set it with dfx identity set-wallet <wallet-id> so that any command you perform with the selected identity will use that wallet to take cycles from/put cycles into. If you do not have one already, go to How to deploy a "hello world" smart contract/dapp in 20 minutes :: Internet Computer and follow 4.4.2.
If you don’t want to link the cycles wallet by default, look at the output of dfx canister delete --help , especially the --withdraw-cycles-to-canister flag

1 Like

Thanks for the answer. I create the canisters with nns-dapp and transfer the ICP to the canisters’ cycles as well - i.e. I don’t use dfx to create canister or handle cycles, I do this in nns-dapp.

My local identity is added as controllers of the canisters.

Therefore not sure chapter 4.4.2 of the documentation apply to this case?

For each cycle transfer IC checks that the remaining cycles are above the freezing threshold. The freezing threshold depends on the memory usage and compute allocation of the canister, so it can increase over time.

The transferCycles function hardcodes 4_100_000 as the freezing threshold, but the returned error says that the freezing threshold is much higher now: the freezing threshold 2057103111 cycles.
Updating the number to something larger than 2057103111 should fix the error.

We are working on exposing freezing_threshold_in_cycles via ic.canister_status(), so in the future there will be no need to hardcode the number in transferCycles.


Indeed @ulan you are right. There is no issue on the network. The problem is that I cannot know the exact freezing threshold in cycles that should be retained and 4_100_ 00 which worked a week ago does not anymore. I set a high value 100_000_000_000 as I had for a long time and I was able to delete the canisters. Thx!