dfinity / sdk

IC SDK: a Software Development Kit for creating and managing canister smart contracts on the ICP blockchain.
https://internetcomputer.org/developers
Apache License 2.0
174 stars 83 forks source link

Always getting "Module hash <hash> is already installed" when trying to upgrade #2516

Open paulyoung opened 2 years ago

paulyoung commented 2 years ago

I'm attempting to upgrade a custom canister locally by calling dfx canister install --mode upgrade <canister name>

I receive a message saying that the module is already installed despite the gzipped Wasm file being different. I even get this message if I remove the real .wasm.gz file and create an empty one at the expected path using touch, or rm the file.

If I try dfx canister install --mode upgrade --upgrade-unchanged <canister name> I see traces from the upgrade hooks but the canister remains unchanged. My assets canister seems unaffected.

I'm using dfx 0.12.0-beta.1

paulyoung commented 2 years ago

I’m not sure if this is related to https://github.com/dfinity/sdk/issues/2459, but I upgraded to the beta version to get that fix.

Now I can deploy again but I can no longer upgrade.

paulyoung commented 2 years ago

I might be able to work around this with dfx canister install --mode upgrade --wasm <canister name>.wasm.gz <canister name>

adamspofford-dfinity commented 2 years ago

A quick test doesn't seem to reproduce this issue - it only marks it as duplicate when the gzip hash is the same. Can you describe the process to reproduce this?

paulyoung commented 2 years ago

@adamspofford-dfinity I'll try to come up with a minimal way to reproduce this.

paulyoung commented 2 years ago

I still haven't gotten around to this but I'm still seeing it consistently locally so will try and get to it soon.

crusso commented 2 years ago

Regardless, I think the behaviour of not upgrading just because the hash is the same is dubious.

A user may want to upgrade just to reset wasm memory to initial conditions, or to test the upgrade process, even without the code having changed. If we keep the behaviour, then '-force' option would be useful.

paulyoung commented 2 years ago

There’s already --upgrade-unchanged but as I mentioned in my original comment, it doesn’t help with this issue.

Using the --wasm flag is the only thing that works for me.

paulyoung commented 1 year ago

I tried creating a minimal example but it doesn't reproduce the issue. When I get some more time I'll try again.