FEATURE REQUEST: If pre_upgrade fails, revert canister to earlier state snapshot of before pre_upgrade ran and discard current pre_upgrade logic

[roman-kashitsyn]

@saikatdas0790

The try_pre_upgrade with a canister upgrade mode of only canister lifecycle changes is a naive solution that I came up with to handle this without making breaking changes to existing API. Probably has holes that I am unable to foresee.

I think I understand what you mean now.

You want the system to execute the following calls during an upgrade:

C1.pre_upgrade()
C2.post_upgrade()
C2.pre_upgrade()

So the system exercises the pre_upgrade hook at least once before accepting the new version.

Note that nothing stops you from calling the pre_upgrade hook from your post_upgrade hook. You don’t need a new system feature for that.

This scheme will save you from trivial errors in the pre_upgrade hooks but not errors caused by increased data size. If I understand correctly, the problem in your case was the following:

C1.pre_upgrade()
C2.post_upgrade()
... C2 functions normally
... Accumulating a lot of data and leaking memory
C2.pre_upgrade() <- traps

If it’s the case, then calling pre_upgrade right after post_upgrade would not have resolved your issue.