async buildRootObject

[warner]

What is the Problem Being Solved?

#3272 turns out to have a surprising requirement: we need to do importBundle (which is async, for deep reasons) from inside buildRootObject (which is sync). This comes from ZCF needing to import the new version of the contract, then invoke the contract method that re-establishes behavior for the durable Kinds, all of which needs to happen before the end of the buildRootObject delivery (so it can execute the normal deliveries that will immediately follow).

D(bundlecap).getBundle() -> bundle is synchronous, for exactly this reason, but I forgot that importBundle is async.

Description of the Design

It looks like making liveslots tolerate an async buildRootObject is the best way to deal with this. The tricky part is the error handling, in particular what to do if the user-provided buildRootObject function returns a Promise that never resolves. We must prevent userspace from hanging the supervisor.

The tail end of startVat currently does:

    const rootObject = buildRootObject(harden(vpow), harden(vatParameters), baggage);
    assert.equal(passStyleOf(rootObject), 'remotable', X`buildRootObject() for vat ${forVatID} returned ${rootObject}, which is not Far`);
    assert(getInterfaceOf(rootObject) !== undefined, X`buildRootObject() for vat ${forVatID} returned ${rootObject} with no interface`);
    // Need to load watched promises *after* buildRootObject() so that handler kindIDs
    // have a chance to be reassociated with their handlers.
    watchedPromiseManager.loadWatchedPromiseTable();

    const rootSlot = makeVatSlot('object', true, BigInt(0));
    valToSlot.set(rootObject, rootSlot);
    slotToVal.set(rootSlot, new WeakRef(rootObject));
    retainExportedVref(rootSlot);
    // we do not use vreffedObjectRegistry for root objects

    vom.insistAllDurableKindsReconnected();
  }

and the code which calls it is basically:

async function dispatch(delivery) {
  const p = Promise.resolve(delivery).then(startVat);
  return waitUntilQuiescent().then(() => p);
}

I'm thinking the trick will be to connect the buildRootObject promise to a function that finishes the startVat process, then sets a flag. We return a separate promise from startVat. I need a way for that second promise to reject if the flag isn't set at the time waitUntilQuiescent fires. That probably means introducing a callback into the () => p portion, to query the flag.

Security Considerations

Main requirement is to not allow an unresolved userspace promise to hang the worker (and kernel).

Test Plan

unit tests

[FUDCo]

Is it considered a valid practice to inspect the return value from a function to see if it's a Promise or not? Or even not look but just fail if a Promise comes back. Because I'd like us to be able to continue using fully synchronous buildRootObject in contexts (basically, tests) that currently assume sync. Otherwise we'll have to update a lot of stuff.

[mhofman]

It's frowned up. The main problem is dealing with thenable objects, especially evil ones.

[FUDCo]

Our tests are not going to be returning evil thenables.

[warner]

I think we can have startVat just do an await upon the return value of buildRootObject like before, so returning a non-Promise should be trivial. The rule will be that buildRootObject must either return the root object, or a Promise which resolves (within the same crank) to the root object, and that all Kinds must be re-established before that Promise returns. If the Promise does not return before end-of-crank, startVat declares failure, same as if buildRootObject throws or returns a rejected Promise.