Manage spawned canisters

[chenyan-dfinity]

Consider the following code with Child1 and Child2 being actor class that have identical Candid interface, but different implementations:

import Child1 "Child1";
import Child2 "Child2";

actor {
  type Child = Child1.Child1;
  let buckets : [var ?Child] = Array.init(100, null);

  public func put(index : Nat) : async () {
    let bucket = switch (buckets[index]) {
      case null { spawn(index) };
      case (?bucket) { bucket };
    };
    ...
  };

  func spawn(index: Nat) : async Child {
    let bucket = if (index > 10) {
      await Child1.Child1(#text "init args")
    } else {
      await Child2.Child2(#num index)
    };
    buckets[index] := bucket;
    bucket
  };
}

If I upgrade this canister (even with the same Wasm), the spawned canisters that were allocated pre-upgrade get lost. Of course, I can make buckets stable, then I can still remember the canister ids after the upgrade. But if the actor class Child1 or Child2 gets a new implementation, I cannot upgrade these spawned canisters even if I still remember the stable buckets array.

One idea to solve this problem is to make a special table in the Motoko stable memory to store allocated canister ids with some metadata (TBD). Before we call create_canister, we consult this table to decide if we want to reuse a previously allocated canister or create a new one. Maybe related to the named adapton idea.

[chenyan-dfinity]

cc @matthewhammer @ByronBecker

[matthewhammer]

Maybe related to the named adapton idea.

In both cases (here and in Named Adapton),

• the programmer chooses names to identify resources that get cached and reused across different running versions
• without these names, it would be impossible to generally align old allocations and their "current uses" in the new, upgraded codebase

unlike in Named Adapton,

• code in the canister gets overwritten (upgraded), not the "input data" for some repeating computation.
• here, there is no "the computation" getting re-run over and over, other than the upgrade hooks. Instead, it's a reactive internet agent that does not necessarily repeat a family of computations over and over, but rather processes new messages and transactions, in an open world.

Still, despite the big differences, perhaps some intuitions from Named Adapton will be helpful.

[chenyan-dfinity]

the programmer chooses names to identify resources that get cached and reused across different running versions

Yes, we can draw on inspirations from adapton to see what's the best syntax to annotate this keyed/named allocation.

here, there is no "the computation" getting re-run over and over

I would argue this simplifies the problem. Essentially, we want to have keyed/named allocation for canister ids, even for unrelated computations. The only thing we instrument/monitor are the management canister calls.