How do I upgrade child canisters that were dynamically created from a parent canister of which I am the controlller (In Motoko)?

Not sure but I would say probably not.

Did you select the main.mo or the Journal.mo wasm code to install the code (wasmModule)?

Good question. I wasn’t aware that the Journal.mo had its own wasm file. Where do i find it?

In the .dfx/ic/canisters Directory, i see three folders: one for my backend, one for my front end and one titled “idl”. The one titled is empty, and the the folder for my backend has only one wasm file. That’s the wasm file i used

also in .dfx in a folder next to your main.mo wasm code

however it might not always present and not always up-to-date with the last build depending of the settings. there is probably a nice way to generate it with a dfx command line but I am not big with the command line, so I generate it with a workaround.

  1. temporarly, in dfx.json add the Journal.mo
  2. dfx build or dfx deploy
  3. above command error will ends in error but it’s alright
  4. you have the wasm code

don’t forget to revert the change in dfx.json when finished.

with 1. I mean for example following. this is my original config

"canisters": {
    "manager": {
      "main": "canisters/src/manager/manager.mo",
      "type": "motoko"
    }
  }

then I add my child canister just to generate the wasm code

"canisters": {
    "manager": {
      "main": "canisters/src/manager/manager.mo",
      "type": "motoko"
    },
    "child": {
      "main": "canisters/src/child/child.mo",
      "type": "motoko"
    }
  }

again there is probably a way to do this by dfx but above generate the wasm code but also the did files what is often handy.

1 Like

Gonna give this a try now

@peterparker , you’re my hero. It worked! i can finally go to bed. its 3:30 AM where I am :smiling_face_with_tear:

2 Likes

awesome, happy to hear that :+1:

3:30 am, such a dedication! sleep well

1 Like

Just to clary, the wasm for an imported actor class is actually embedded in the wasm of the importing code.

Adding the additional compilation target to the dfx.json, (thus compiling the imported class on its own) has the side-effect of producing the wasm of the imported class as a separate, non-embedded thing.

As far as I know, that’s the only way to do this just now.

I’ve considered making the wasm of an imported class programmatically accessible as a blob somehow, or, alternatively, providing additional functions to perform manual installation/upgrade with all IC parameters exposed in the imported library (in addition to the class constructor), but they all seem like hacky solutions and are difficult to make type safe.

4 Likes

Thanks for the explanation Claudio :+1:

About the “hacky solutions”, no rush for me, I can live with my current “hacky” solution :wink:.

1 Like

Are there any breaking/differing behavior or “got-yas” once a canister is upgraded in the way @peterparker has outlined?

For example, if I would imagine that if I upgrade each of the canisters independently in this way, I would also need to redeploy the main canister as well so that it also has the new correct child canister wasm embedded in it in order to allow the main canister to continue dynamically spawning more child canisters.

Are there any additional side effects to keep in mind when updating settings, uninstalling, stopping, or deleting canisters through the main canister after such an upgrade of all the child canisters?