after i created a canister via a canister, the new one’s balance is 500_000_000_000 and it’s asking me to topup to install code on it.
i decided to delete it and fix the canister’s code that creates the canister… but the cycles on the new one is not refunded to the creator canister.
is there a reason why? or the delete canister has a fee?
Hi there
Did you uninstall your code or delete your canister? In the latter case, the cycles are lost.
Otherwise, you can just reinstall code on the same canister id and use the cycles. If you don’t want to use that canister id anymore, you can install a wallet canister on that canister id and transfer your cycles out.
i see. it’s an expensive lesson for me then. may i know why the design is like this instead of refunding the cycle balance back the installer or controller?
also when i was done fixing the code, and try to upgrade, it keeps on throwing the error: the install code must have at least N amount. but when i topped it up, it threw the same error again but with M amount, later K amount, then J amount, and so on but i keep on topping it up… until i decide to topup 10x the amount then it resolves. it’s a bad dev experience tbh due to the misleading error " canister must have at least this amount". maybe a better approach is to specify the recommended amount for a successful upgrade.
The installer is not known, and there may be many controllers. To which one should the cycles go? Even if there was a single controller, only canisters can hold cycles, not arbitrary principals (the system was designed way before the cycles ledger which gives the illusion that any principal can hold cycles).
DFX has a command for moving most cycles out of a no longer used canister, you may want to use that in the future. Check the DFX documentation.
I’ll forward your feedback about the “least amount of cycles” internally, thanks!
The error response from the IC about the minimum amount of cycles is as good as it can be, but unfortunately parameters can change quickly in a few seconds. E.g., if your canister suddenly uses a bit more memory, then its freezing threshold is larger, and the amount that was correct a second ago no longer suffices. But this is not something the system can predict, so it gives a lower bound to the best of its knowledge.
Hi Michael, could you elaborate on that? I couldn’t find anything like this in the dfx documentation, other than installing the wallet canister wasm and then interacting with this to transfer out. Or is this what you were referring to?
Turns out, dfx canister delete does this by default: dfx canister | Internet Computer
Can you elaborate more on these errors? Because normally only 300B + change (310B is enough) are required to be able to install code or upgrade code in a canister. Not 500B or more. Was there something special in your case, for example, did you have a very long freezing threshold set, was the wasm module to install very large, was the memory footprint of the canister very large before the upgrade, etc?
This assumes a 13-nodes subnet. The required amount of cycles is larger on a fiduciary subnet:
34/13 * 300B ~ 784.61B