Problem upgrading front-end canister on IC

I am trying to upgrade an IC deployment with new code (Rust backend and vue.js frontend). It deploys nicely and works perfectly locally. The canister-ids.js file is as follows:

{
  "rust_simplifire": {
    "ic": "redgg-aaaaa-aaaap-qaesa-cai"
  },
  "rust_simplifire_assets": {
    "ic": "rdcas-nyaaa-aaaap-qaesq-cai"
  }
}

The Rust canister appears to upgrade OK:

$ dfx canister --network ic install --mode=reinstall rust_simplifire
WARNING!
You are about to reinstall the rust_simplifire canister
This will OVERWRITE all the data and code in the canister.

YOU WILL LOSE ALL DATA IN THE CANISTER.");


Do you want to proceed? yes/No
yes
Reinstalling code for canister rust_simplifire, with canister_id redgg-aaaaa-aaaap-qaesa-cai

But the front-end canister upgrade fails as follows:

dfx canister --network ic install --mode=reinstall rust_simplifire_assets
WARNING!
You are about to reinstall the rust_simplifire_assets canister
This will OVERWRITE all the data and code in the canister.

YOU WILL LOSE ALL DATA IN THE CANISTER.");


Do you want to proceed? yes/No
yes
Reinstalling code for canister rust_simplifire_assets, with canister_id rdcas-nyaaa-aaaap-qaesq-cai
Error: No such file or directory (os error 2)

Not sure what I’m doing wrong. Any suggestions most welcome.

Dave

I think the error message might be improved in newer versions of dfx but I would compare the files you have on disk with the file paths mentioned in your dfx.json and see if something is missing.

Did you recently upgrade to newer version of dfx v0.11.0? Not sure it is related but there is a breaking change regarding assets that was announced in this thread Dfx 0.11.0 is promoted with breaking changes

Check the source config in dfx.json. Are all the directories listed there actually present?

I can see the dfx.json source files & directory fine from the root directory, Kyle. dfx.json is:

"canisters": {
    "rust_simplifire": {
      "candid": "src/rust_simplifire/rust_simplifire.did",
      "package": "rust_simplifire",
      "type": "rust"
    },
    "rust_simplifire_assets": {
      "dependencies": [
        "rust_simplifire"
      ],
      "frontend": {
        "entrypoint": "dist/rust_simplifire_assets/index.html"
      },
      "source": [
        "dist/rust_simplifire_assets/"
      ],
      "type": "assets"
    }
  },
  "defaults": {
    "build": {
      "args": "",
      "packtool": ""
    }
  },
  "dfx": "0.9.3",
  "networks": {
    "local": {
      "bind": "127.0.0.1:8000",
      "type": "ephemeral"
    }
  },
  "version": 1

We’re still on dfx 0.9.3. Should we upgrade?

I see two odd things here - the entrypoint is pointing to your dist directory. Generally Webpack uses this to determine the entrypoint for your code bundling.

Can you confirm that your npm build job is successfully outputting to dist/rust_simplifire_assets and not just dist? Providing your webpack config may help too

1 Like

We do have the dist/rust_simplifire_assets folder. Our webpack config can be seen on this link: simplifire-ic/webpack.config.js at master · Simplifire/simplifire-ic · GitHub

I seem to have found a way around the problem, Kyle. I used sudo dfx -v deploy --network ic instead of dfx canister --network ic install --mode=reinstall rust_simplifire

It deployed the two canisters:

Deployed canisters.
URLs:
  Frontend:
    rust_simplifire_assets: https://rdcas-nyaaa-aaaap-qaesq-cai.ic0.app/
  Candid:
    rust_simplifire: https://a4gq6-oaaaa-aaaab-qaa4q-cai.raw.ic0.app/?id=redgg-aaaaa-aaaap-qaesa-cai

The new code is visible through the frontend URL and, upon initial testing, all looks good.

Should we continue to use this for new versions of code (noting that we are still in prototype mode so loss of data is not an issue)?

Thanks

Dave

dfx deploy --network ic is a perfectly fine pattern, and won’t delete your canister’s state like --mode=reinstall does. If you need to use sudo, there’s something weird about your dfx installation

I remember having issue with permission on OSX too. If @DaveyEbb you deploy on OSX too and if it can be useful, here what solved my scheme: Permissions on OSX - #2 by peterparker

1 Like