We are fairly certain there was a wasm at 5h7ky-2yaaa-aaaak-aenva-cai in April. Now there is none. We are trying to figure out if it was removed due to cycle drain or if there was a deliberate deletion via dfx. Is there any way to audit that? How long would it take to have a canister burn through its freezing threshold?
The default freezing threshold is ~ 30 days
I don’t think there’s a way to find out how it got deleted.
Although it won’t help for the canister mentioned in this thread, in the future the new canister_info functionality should help with this type of question.
The canister history consists of a list of canister changes (canister creation, code uninstallation, code deployment, or controllers change). Every canister change consists of the system timestamp at which the change was performed, the canister version after performing the change, the change’s origin (a user or a canister), and its details. The change origin includes the principal (called originator in the following) that initiated the change and, if the originator is a canister, the originator’s canister version when the originator initiated the change (if available). Code deployments are described by their mode (code install, code reinstall, code upgrade) and the SHA-256 hash of the newly deployed canister module. Canister creations and controllers changes are described by the full new set of the canister controllers after the change.
We have plans to use this functionality to display canister history on the IC dashboard.
@domwoe @Dylan I suppose canister deletion happens automatically when there are no cycles to pay for it correct?
Is there a way to monitor the usage, so that developers can send more cycles to the canister? Ideally automated, but at least in manual mode.
As a controller, you can access the balance using canister_status
, but there are other ways to monitor the balance, see GitHub - dfinity/awesome-internet-computer: A curated list of awesome projects and resources relating to the Internet Computer Protocol for some suggestions.
I’d recommend having a look at CyclΞOps
Canisters get uninstalled once they run entirely out of cycles (source), but the (empty) canister is kept alive for ~10 years IIRC, so if the canister is deleted, then I’d expect it to have been manually deleted
Thank you for bringing this up.
I thought deleting a canister and running out of cycles would have the same effect, but I misremembered.
According to Interface Spec:
Deleting a canister cannot be undone, any state
stored on the canister is permanently deleted and its cycles are discarded. Once a canister is deleted, its ID cannot be reused.
This would imply that also the controller information gets deleted if I understand it correctly.
whereas running out of cycles leads to:
When the cycle balance of a canister falls to zero, the canister is deallocated. This has the same effect as
uninstalling the canister (as described in IC method)
setting all resource reservations to zero
Afterwards the canister is empty. It can be reinstalled after topping up its balance.
Looking at Canister: 5h7ky-2yaaa-aaaak-aenva-cai - ICP Dashboard, the controller information is available. Therefore, if the canister has a balance of 0, it means it has run out of cycles, and you can top it up and install the old (or another) wasm module. If someone uninstalled the wasm module, the cycles balance should not be zero. If the canister was manually deleted, then it would not be possible to top up and install a new wasm module.
@Severin @domwoe First thanks for shedding light on this topic, which is still hard to fully understand.
So if a canister is about to run out of cycles, there are ways to monitor this and hopefully prevent it. Thanks @domwoe for the links.
But what confuses a bit is the long explanation, and the fact that even without cycles the canister continues to exist and can be revived as @Severin and @domwoe mentioned. Does this mean that:
- The revived canister code would be back alive, and all code would be untouched? What is actually revived with the cycle top-up?
- I assume all data saved in stable Rust data structures is gone, is that the case?
Thanks.
When the canister runs out of cycles only its metadata is preserved. The code and data/state are deleted.
Thanks Dominic, yes that is what I thought.
So the 10 years life, is the life of a corpse
how is the deletion process triggered? is there a timely check if the canister has enough cycles or not to pay for the storage or the state gets deleted as soon as there is no cycles?
AFAIK cycles balances are updated every 10 seconds or so, and I assume that is also when dropping the canister state would happen