Great topic, your wiki is wonderfull!
1 Like
If I make a change to the pre_upgrade hook for a canister and then redeploy the canister, maybe that pre-upgrade code could take effect immediately (on the pre-upgrade for the current upgrade) instead of for future upgrades (which is what currently happens, I think)? Is that a bad idea?
So if we imagine the canister as two separate pieces of state: the wasm module and the wasm memory, then I think your proposal is to have an ability to replace the wasm module without replacing the wasm memory. Is that correct?
Yes, I think this will help but this may not solve all the problems that fall under the class of “bugs in the pre_upgrade hook” I think. What if the bug is in the wasm memory itself?
The current idea that I am contemplating is to allow the developer to be able to download the entire canister state. Then the developer could (using some additional tools that we may have to develop) fix the canister (by either modifying the wasm module or the memory itself); run a bunch of tests to make sure they fixed it properly; and then have the ability to upload the canister state.
I think it might be better to let developers do debugging offline where if they make mistakes, they do not make a bad problem worse.
3 Likes
I think we need that anyways for debugging (and I think I’m not the only one) eventually, and agree that it’s a good measure of last resort. Else, the advice to avoid preupgrade and ideally make you canister upgradeable without stopping stands 
The current idea that I am contemplating is to allow the developer to be able to download the entire canister state. Then the developer could (using some additional tools that we may have to develop) fix the canister (by either modifying the wasm module or the memory itself); run a bunch of tests to make sure they fixed it properly; and then have the ability to upload the canister state.
Interesting, that sounds quite useful. I suppose this would be used more for fixing bugs rather than performing schema migrations + backfills, since modifying stable memory wouldn’t be possible off-chain I think.
I was testing upgrade today and realized what he said, if the pre_upgrade traps, you literary cannot upgrade the canister ever again. The pre_upgrade that run is the one installed in the canister, not the one you are deployng. I took a long time to understand this, this should be more clear in the docs, I would put a big red flag on this.
1 Like
I only realized that during this discussion:
2 Likes