In general, the canister upgrade story still has a lot of foot guns that need addressing. I want to highlight the following known foot guns. I may have missed some Bugs in pre_upgrade hooks If there is a bug in your pre_upgrade hook that causes it to panic, the canister can no longer be upgraded.…

[image] jzxchiang: Wow interesting. So upgrading stopped canisters is merely a recommendation and not a requirement, is that right? I personally think that it should be a requirement. AFAIK, no compiler can guarantee that the new wasm will be compatible with the older wasm, so no realistic w…

[image] akhilesh.singhania: so no realistic wasm module (i.e. not hand crafted) can manage this. I think that’s too pessimistic. Just because the two compilers we use right now can’t do this doesn’t mean that we should at least allow someone to do better - either improving the compilers, or m…

Motoko will actually prevent an upgrade if the canister has pending call-backs.

I was of course referring to all the wasm modules that I have seen in the wild and what our developers are building. IMO, having a more restrictive system initially and then relax the constraints when we have built sufficient capabilities is probably a more user friendly approach than having a less…

Foot gun guards are better placed in layers above the system, I’d say. And as Claudio points out Motoko does that - the rust CDK should probably too. The problem with putting restrictions into the system is that it stifles innovation: Assume the system would prevent such upgrades, and you’d be in …

Thanks. What’s the difference between ic0.msg_reply / ic0.msg_reject and the inter-canister call callbacks that are stored inside the canister table?

Let’s say canister A sends a request to canister B. If you look at the arguments to ic0.call_new() here: The Internet Computer Interface Specification :: Internet Computer , the reply_fun and reply_env identify the function to be called if B replies to A using ic0.msg_reply and reject_fun and reject…

Looks like we are in agreement here. I am perfectly happy if it is the CDKs that are protecting the users from the footguns. The system should indeed be more expressive.

[image] nomeata: The ledger only sends notifies without caring about the result, just throwing them away, and makes no other calls? Just checked, unfortunately the ledger does not just use “one-shot” calls, but has logic in the response handler. Too bad. But we can still extract a pattern: i…

I am maintaining a list of current limitations of the IC on Current limitations of the IC - Internet Computer . I would love to clean up the discussion there and add more limitations to the page. Contributions are welcome!

Watch out for foot guns with canister upgrades

Developers

paulyoung July 24, 2022, 8:45pm 27

I only realized that during this discussion:

Topic		Replies	Views
FEATURE REQUEST: If pre_upgrade fails, revert canister to earlier state snapshot of before pre_upgrade ran and discard current pre_upgrade logic Rust	39	1811	January 18, 2023
The biggest problem with the IC - InterCanister Calls Developers	26	3040	July 28, 2022
Canisters Capacity - Upgrade Motoko	0	61	December 16, 2025
How do I upgrade child canisters that were dynamically created from a parent canister of which I am the controlller (In Motoko)? Developers	33	2320	November 16, 2022
Queue + failing heartbeat + stopping canister = death spiral Developers	34	2185	September 14, 2022

Watch out for foot guns with canister upgrades

Related topics