You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
dfinity/interface-spec#135 adds a new canister upgrade mode to support data-recovery in the case of a failed pre_upgrade hook. We should consider taking advantage of this somehow, if at all possible.
It's not at all clear this upgrade mode is that useful to Motoko canisters, unless they maintain all data in stable memory/regions and don't use stable variables at all. This because Motoko relies on a compiler generated pre_upgrade hook (as well and an optional, user provided one). In this upgrade mode all (in heap) stable variable data will be lost yet most stable memory is only accessible via stable variables containing isolated regions.
We would need at the very least to implement a full recovery mechanisms for regions, I think. For example, Motoko would need to recognize, on upgrade, that stable variable data had not been serialized (perhaps by examining stable memory and looking for signs of absent serialization data) and enter some sort of recovery mode, perhaps by calling a function that recovers stable regions from the metadata.
The text was updated successfully, but these errors were encountered:
I believe the IC pre-upgrade skip option does not make sense for Motoko as it's internal functionality is used for preparing EOP and/or graph copy upgrade. What we could consider is a user-level option to skip the application-implemented pre-upgrade hook. With EOP, I believe though, we should guide developers not to use upgrade hooks at all in Motoko.
dfinity/interface-spec#135 adds a new canister upgrade mode to support data-recovery in the case of a failed pre_upgrade hook. We should consider taking advantage of this somehow, if at all possible.
It's not at all clear this upgrade mode is that useful to Motoko canisters, unless they maintain all data in stable memory/regions and don't use stable variables at all. This because Motoko relies on a compiler generated pre_upgrade hook (as well and an optional, user provided one). In this upgrade mode all (in heap) stable variable data will be lost yet most stable memory is only accessible via stable variables containing isolated regions.
We would need at the very least to implement a full recovery mechanisms for regions, I think. For example, Motoko would need to recognize, on upgrade, that stable variable data had not been serialized (perhaps by examining stable memory and looking for signs of absent serialization data) and enter some sort of recovery mode, perhaps by calling a function that recovers stable regions from the metadata.
The text was updated successfully, but these errors were encountered: