What means this error?

Developers
1

Canister rdmx6-jaaaa-aaaaa-aaadq-cai has different hash between on chain and download.

1 Like
2

This error means the version downloaded wasm is not the same as the wasm_hash metadata or the hash of the canister deployed on the mainnet.

In other words, it means that the version of Internet Identity canister is different than the up-to-date version of the Internet Identity canister deployed on mainnnet.

If you want to explore the error more technically, you can also see the source code where the error is being returned: sdk/src/dfx/src/commands/deps/pull.rs at 9fd111de914cf43af05ac037c55dccfc9cf430ae · dfinity/sdk · GitHub.

Are you doing a dfx deps pull?

3

I am having the same problem. Pulling II canister for local dev. My first deploy to main net so maybe there is something I am missing.

Thanks!

4

That is actually on purpose. The production version of II is not very convenient to use for local testing, so you automatically pull the dev build where e.g. the captcha is always the same

1 Like
5

I am getting this warning:

 dfx deps pull                                                                      ✔  4s  
Fetching dependencies of canister rdmx6-jaaaa-aaaaa-aaadq-cai...
Found 1 dependencies:
rdmx6-jaaaa-aaaaa-aaadq-cai
Pulling canister rdmx6-jaaaa-aaaaa-aaadq-cai...
WARN: Canister rdmx6-jaaaa-aaaaa-aaadq-cai has different hash between on chain and download.
on chain: a3b50a3b35c487b9e5e9cd0174845d83fe15d5bb5d78e507647ed2272777568f
download: 197d0423178a6ae2785c924b962648e2b47e6ccb2a25e98d9220d9f3ce5eebf7

I deleted the .cached II canister and still encountering the same issue.

6

I was able to replicate the error that you and another developer on Discord are having.

When I do a dfx deps pull:

  1. The pulled wasm at /Users/myusername/.cache/dfinity/pulled/rdmx6-jaaaa-aaaaa-aaadq-cai/canister.wasm.gz hash is 197d0423178a6ae2785c924b962648e2b47e6ccb2a25e98d9220d9f3ce5eebf7.

  2. However, in my project, the expected hash in pulled.json is:
    a3b50a3b35c487b9e5e9cd0174845d83fe15d5bb5d78e507647ed2272777568f

It seems like the issue is that the cached WASM is using the dev version of II.

I tried to remove the cache by running dfx cache. @Severin Do you know what potentially could be the issue?

7

Hi everyone

II dev here. Everything is behaving as expected.

We recently restructured our CI infrastructure to simplify our build process. While doing that, we stopped providing the hash of the pulled dev build wasm (to get rid of the dependency between prod and dev artifacts). This results in the warning being printed. You can check the II release page to make sure the hashes line up: Release release-2024-02-16: Various Small Improvements · dfinity/internet-identity · GitHub

Sorry for the confusion. We clearly underestimated how much people care about the warning.
I’ll pick this up internally to improve the situation, so that no warning is being printed if everything working as intended.

Thanks for the feedback!

1 Like
8

So the warning actually prevents me from deploying. I am still uncertain as how to fix this.

1 Like
9

What version of dfx are you using?

Try updating to the latest version, which should allow deployment despite the warning.

10

I am using 0.17.0. It still doesn’t allow me to proceed. I tried ignoring the warning after I pulled and got this again:

dfx deps init internet_identity --argument '(null)'                               ✔  12s  
Error: The pulled wasm of rdmx6-jaaaa-aaaaa-aaadq-cai has different hash than in pulled.json:
    The pulled wasm is at "/home/porter/.cache/dfinity/pulled/rdmx6-jaaaa-aaaaa-aaadq-cai/canister.wasm.gz". Its hash is:
        197d0423178a6ae2785c924b962648e2b47e6ccb2a25e98d9220d9f3ce5eebf7
    The expected hash in pulled.json is:
        a3b50a3b35c487b9e5e9cd0174845d83fe15d5bb5d78e507647ed2272777568f
11

Thanks @paulous. In that case, this seems to be a bug.

I will ping you again once this has been resolved. Sorry for the inconvenience.

1 Like
12

Not at all, thanks for the very fast response. I know what a huge undertaking the IC is and am just very exited to see it grow.

1 Like
13

Hi @Tobarrientos2 and @paulous,

I’m in charge of dfx deps. The warning about hash mismatch was a recently added feature. It is expected in this case. My colleagues has provided some good explanations above.

Your feedback indeed reveals an undesired behavior of dfx deps:
dfx deps pull allows mismatch hash while the following dfx deps init still requires hash check.

I’ll fix it on dfx deps side ASAP.

And I’ll remove the warning since it is not very helpful for canister consumers like you. (Consumers can’t “fix” it locally.)

4 Likes
14

Thank you @lwshang and @frederikrothenberger for the input!

1 Like
15

Hi @Tobarrientos2 and @paulous,

The fix PR on the dfx side has been merged. The next dfx release (expected in the week of March 4th) will include this fix.

I also came up with a workaround that will unblock you even without the fixed dfx deps.

Step 1

Declare internet-identity as a pull type canister in dfx.json.

{
  "canisters": {
    "ii": {
      "type": "pull",
      "id": "rdmx6-jaaaa-aaaaa-aaadq-cai"
    }
  }
}

Step 2

Run dfx deps pull:

$ Fetching dependencies of canister rdmx6-jaaaa-aaaaa-aaadq-cai...
Found 1 dependencies:
rdmx6-jaaaa-aaaaa-aaadq-cai
Pulling canister rdmx6-jaaaa-aaaaa-aaadq-cai...
WARN: Canister rdmx6-jaaaa-aaaaa-aaadq-cai has different hash between on chain and download.
on chain: a3b50a3b35c487b9e5e9cd0174845d83fe15d5bb5d78e507647ed2272777568f
download: 197d0423178a6ae2785c924b962648e2b47e6ccb2a25e98d9220d9f3ce5eebf7

Step 3

Replace the “wasm_hash” field in deps/pulled.json with the download hash you see above.

{
  "canisters": {
    "rdmx6-jaaaa-aaaaa-aaadq-cai": {
      "name": "ii",
      "wasm_hash": "197d0423178a6ae2785c924b962648e2b47e6ccb2a25e98d9220d9f3ce5eebf7",
      "init_guide": "Use '(null)' for sensible defaults. See the candid interface for more details.",
      "init_arg": null,
      "candid_args": "(opt InternetIdentityInit)",
      "gzip": true
    }
  }
}

Step 4

The following dfx deps init/deploy will work.

$ dfx deps init
Canister rdmx6-jaaaa-aaaaa-aaadq-cai (ii) set init argument with "(null)".

$ dfx start --clean --background
...

$ dfx deps deploy
Installing canister: rdmx6-jaaaa-aaaaa-aaadq-cai (ii)

$ dfx canister call ii captcha_create
(
  variant {
    Ok = record {
      png_base64 = "...";
      challenge_key = "...";
    }
  },
)
4 Likes
16

Thanks for the info. I can wait but good to know there’s a fix if needed.

17

@paulous: the problem will be fixed, once this proposal is accepted.

1 Like
18

Thanks! Appreciate the update.