TLDR: Why do canisters temporarily dump excess cycles during an upgrade?
I was testing out upgrading canisters with an intermediate amount of data on main net (200+ MB) and ran into the following error.
Canister installation failed with `Canister ael4e-2yaaa-aaaan-qakia-cai is out of cycles: requested 80_000_590_000 cycles but the available balance is 204_292_897_802 cycles and the freezing threshold 186_257_633_040 cycles
This makes sense, although the upgrade requesting 80 billion cycles does sound like overkill. So I went ahead an topped up the canister and completed the upgrade.
I then went forward and started upgrading additional canisters (with similar amounts of data) while simultaneously pinging their cycles balances, and noticed the following strange behavior.
- Before upgrading canister A, A has cycles balance = 0.615 T cycles
- Start upgrade of canister A
- Immediately poll the cycles balance of canister A (during the upgrade). At some point during the upgrade, the canister will temporarily return a cycles balance of ~0.535T (roughly 80 billion cycles less, gone in an instant)
- Several seconds later, the upgrade has finished. Poll the cycles balance of canister A again. Canister A now shows a balance of 0.608T cycles.
During canister upgrades, why do canister cycles balances temporarily dump cycles before getting “topped” back up? Is this to hold an excess to protect canisters against failed upgrades?
Also, in all of the failed cases, I found that the upgrade was requesting
80_000_590_000 cycles. Is there something magic about 80 billion cycles as to why this number was chosen?