What I’m proposing is introduction of another hook, something like
try_pre_upgradethat runs the logic in the hook. If everything works as expected, it will behave exactly likepre_upgradecurrently does.However, if there’s a panic during the
pre_upgradestep, it will simply revert to the last working checkpoint exactly how panics during update calls behave right now.
Maybe I misunderstand, but a trap in the pre_upgrade hook already causes a rollback, so how is that different?
Additionally, add another upgrade mode to the existing
upgrade,install,reinstallcalledlifecycle_upgradethat lets us upgrade only the lifecycle hooks in canisters while retaining their current heap. I imagine this can also borrow implementation logic from how canisters are put to sleep and woken up on the execution layer. Something around saving the entire heap memory contents to stable storage.
Of course that desire is understandable, and I agree that some solution is needed.
However, the fundamental reason why we have upgrade hooks in the first place instead of persisting the heap through upgrades is the fact that code changes can change the heap layout. That is a fact of life with almost every interesting compiler, including Rust and Motoko (e.g., because memory regions move, pointers change, indices shift, etc.). And it implies that new code can not use the old heap.
Unfortunately, adding, removing, or replacing upgrade hooks is a code change as well. In fact, even recompiling the exact same source code might change the heap layout if you are using a different compiler version or different compiler options!
Thus, we simply cannot assume that a heap image still is valid and safe to use after an upgrade, no matter how small the change.
If you need stable heap layout, then your only option currently is to use stable memory directly, and manually lay out your data in it. But then the responsibility is all yours that this layout remains backwards compatible. I would hope that the community would eventually build some decent libraries for that.