Mismatch in argument count when calling function doResolve

[andrey-kuprianov]

Surfaced from @informalsystems Agoric Audit of Agoric/agoric-sdk/SwingSet hash 23ed67c

Uncovered by renaming kernel.js to kernel.ts and running tsc.

src/kernel/kernel.ts:405:7 - error TS2554: Expected 3 arguments, but got 2.

405       resolveToError(msg.result, VAT_TERMINATION_ERROR);
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  src/kernel/kernel.ts:339:44
    339   function resolveToError(kpid, errorData, expectedDecider) {
                                                   ~~~~~~~~~~~~~~~
    An argument for 'expectedDecider' was not provided.

In multiple places in kernel.js function resolveToError is called with 2 arguments instead of 3. At the same time, in 2 places it is actually called with 3 arguments. Here is the function:

  function resolveToError(kpid, errorData, expectedDecider) {
    doResolve(expectedDecider, [[kpid, true, errorData]]);
  }

It calls doResolve:

function doResolve(vatID, resolutions) {
    if (vatID) {
      insistVatID(vatID);
    }
    for (const resolution of resolutions) {
      const [kpid, rejected, data] = resolution;
      insistKernelType('promise', kpid);
      insistCapData(data);
      const p = kernelKeeper.getResolveablePromise(kpid, vatID);
      const { subscribers, queue } = p;
      let idx = 0;
      for (const dataSlot of data.slots) {
        kernelKeeper.incrementRefCount(dataSlot, `resolve|s${idx}`);
        idx += 1;
      }
      kernelKeeper.resolveKernelPromise(kpid, rejected, data);
      notifySubscribersAndQueue(kpid, vatID, subscribers, queue);
      const tag = rejected ? 'rejected' : 'fulfilled';
      if (p.policy === 'logAlways' || (rejected && p.policy === 'logFailure')) {
        console.log(
          `${kpid}.policy ${p.policy}: ${tag} ${JSON.stringify(data)}`,
        );
      } else if (rejected && p.policy === 'panic') {
        panic(`${kpid}.policy panic: ${tag} ${JSON.stringify(data)}`);
      }
    }
  }

This function in turn passes the (possibly undefined) vatID to getResolveablePromise and notifySubscribersAndQueue.

  function getResolveablePromise(kpid, expectedDecider) {
    insistKernelType('promise', kpid);
    if (expectedDecider) {
      insistVatID(expectedDecider);
    }
    const p = getKernelPromise(kpid);
    assert(p.state === 'unresolved', X`${kpid} was already resolved`);
    if (expectedDecider) {
      assert(
        p.decider === expectedDecider,
        X`${kpid} is decided by ${p.decider}, not ${expectedDecider}`,
      );
    } else {
      assert(!p.decider, X`${kpid} is decided by ${p.decider}, not the kernel`);
    }
    return p;
  }

This function seems to expect that expectedDecider may be undefined. On the other hand,

  function notifySubscribersAndQueue(kpid, resolvingVatID, subscribers, queue) {
    insistKernelType('promise', kpid);
    for (const vatID of subscribers) {
      if (vatID !== resolvingVatID) {
        notify(vatID, kpid);
      }
    }
    // omitted for brevity
  }

doesn't seem to be caring about resolvingVatID being possibly undefined.

Recommendation: While the current code may work fine with the mismatching argument lists, this may lead to errors in the future, as it introduces implicit assumptions down the whole call chain. We recommend to refactor all relevant functions into two variants: one with the VatID argument present, and another, without it.

[erights]

Recommendation: While the current code may work fine with the mismatching argument lists, this may lead to errors in the future, as it introduces implicit assumptions down the whole call chain. We recommend to refactor all relevant functions into two variants: one with the VatID argument present, and another, without it.

@andrey-kuprianov ,
Is there a reason to do that rather than explicitly declare expectedDecider to be an optional argument?

I certainly agree we should do one or the other. In general our style has been to make generous use of optional arguments but only stingy use of duplicated code logic. The later is a refactoring hazard.

[andrey-kuprianov]

I agree, it is completely fine to declare expectedDecider an optional argument. The only point I wanted to make is that for each function it should be completely transparent about its calling conventions. Implicit assumptions become especially dangerous with time, when new developers come: they don't share those assumptions, and can thus violate them.

I would like to draw a parallel with a similar issue we've encountered during the IBC audit, where implicit assumptions have also almost lead to a bug: cosmos/ibc-go#68.