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?
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
--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
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!