Upgrade a canister even if the Wasm module hash has not changed

Is there a way to trigger a canister upgrade even if the module hash has not changed? I often want to do this when testing, and especially right now as I am testing stable storage in Azle, so I want to just force some upgrades even without code changes.

Does dfx canister install --mode=reinstall … do what you want?

1 Like

It seems like that completely removes the state and code and reinstalls the code, calling init again. I want the pre_upgrade and post_upgrade functions to run even if the module hasn’t changed. And even if that did work, the fact that it has a prompt would make it difficult to use in a CI environment.

To bypass prompts, use the yes utility. Something like:

yes "yes" | <whatever script has prompts>

I used it in my CI like this:

I used this for the Motoko warning for loss of stable variable data, it’s from dfx 0.9.2 which had this bug of showing the warning even though it was safe to upgrade

If dfx doesn’t allow you to upgrade to identical code, I’d consider that a bug. Hopefully community contributions are open for the sdk repo soon, so that I can tell people to just fix it :slight_smile:

1 Like

PSA: Do not use yes in any CI that involves macOS, as multiple concurrent tasks on the same machine will deadlock as both fight for 100% CPU. We’ve been bitten by that several times. echo yes will provide the intended effect.

2 Likes

I’ve used a hack in the past by just adding/altering an empty public function and removing/reverting it after the tests with sed (bash). This way the hash changes, and you can test pre and post upgrade functions.

I would love a better solution tho…

Yes, it was fixed in dfx 0.9.3

image

Oh, I was not aware of this. Our CI runs on Ubuntu and we haven’t run into trouble with yes yet. But will keep this in mind :slight_smile: