async: cancellation continuation double-consumes resolution delivered to a sibling #345

Summary

Async subtask.cancel's determinacy park clears its synchronous claim
(hasSyncWaiter = false) before the callee's cancellation actually
becomes determinate. During that window a sibling waitable.join +
waitable-set.poll is legal and can consume the subtask's SUBTASK
resolution event first. When the cancellation continuation resumes, it
tries to consume the same event again and hits an assertion — the
resolution is delivered to two different consumers.

Baseline: 1a4f5e1c6f3fc906ce576acdc4499ef2745d6e41.

Where

• runtime/src/intrinsics/async_builtins.ts:462-480 —
  the async determinacy park: st.hasSyncWaiter = false runs at park
  entry (line 468) and again in produce/onSettled (lines 475, 479),
  releasing the claim while the subtask may still resolve and deliver
  its event to whichever consumer polls first.
• runtime/src/intrinsics/async_builtins.ts:344-360 —
  finishSubtaskCancel's tail (finish, invoked from produce at line
  476) calls st.getPendingEvent() at line 349 unconditionally once
  st.resolved() is true, without checking whether the event was
  already consumed by another waiter.
• runtime/src/task/waitable.ts:62-65 —
  getPendingEvent() asserts pendingEvent !== null, which is what
  actually fires.

Authorities

• third_party/component-model/design/mvp/canonical-abi/definitions.py,
  canon_subtask_cancel: sets has_sync_waiter before on_cancel()
  and clears it once the claim ends, for both the sync and async forms.
  The claim exists precisely so a subtask cannot be consumed by two
  waiters at once (mirrored by the trap_if(subtask.in_waitable_set())
  check at lines 393-401 of async_builtins.ts, and by
  canon_waitable_join's trap_if(w.has_sync_waiter)).

• docs/architecture.md §6 —
  names the async determinacy park as a deliberate non-atomicity
  divergence from the reference (issue scheduler/docs: async subtask.cancel determinacy park weakens built-in atomicity — record divergence + seeded regression test #92): "other ready threads may
  run before this built-in returns." That divergence is scoped to
  reordering which thread runs first, not to permitting a second
  consumer of the same resolution event. The comment at
  async_builtins.ts:464-467 reads scheduler/docs: async subtask.cancel determinacy park weakens built-in atomicity — record divergence + seeded regression test #92 as license for the claim release
  itself:

  Async cancellation releases its synchronous claim before the
  determinacy park, allowing a sibling's waitable.join. Issue scheduler/docs: async subtask.cancel determinacy park weakens built-in atomicity — record divergence + seeded regression test #92
  permits reordering, not a new trap condition.

  But scheduler/docs: async subtask.cancel determinacy park weakens built-in atomicity — record divergence + seeded regression test #92's scope is reordering of thread execution order, not
  reordering of who is allowed to consume this subtask's resolution.
  Releasing hasSyncWaiter mid-park hands the resolution to whichever
  waiter polls first, and the cancellation continuation has no way to
  discover it lost the race — it unconditionally calls finish(),
  which asserts.

Existing coverage that documents "legal" but doesn't consume

runtime/tests/subtask_cancel_sync_waiter_window_test.ts asserts that a
sibling waitable.join is legal once hasSyncWaiter is cleared during
the async park window, but the sibling in that test never actually
calls waitable-set.poll/consumes the event before the cancellation
continuation resumes. It documents the window is open without
exercising what happens if something walks through it.

Reproduction (standalone, repo-relative)

From runtime/, given the same import-map (deno.json) as the
package's own tests:

// runtime/repro_cancel_race.ts
const root = new URL("./src/", import.meta.url).href;
const m = await import(root + "task/mod.ts");
const a = await import(root + "intrinsics/async_builtins.ts");

const store = new m.Store();
const inst = new m.ComponentInstanceState(0, store);
const ft = { params: [], results: [], async: true };
const opts = { async_: true, callback: false, stringEncoding: "utf8", memory: null };

// Caller task performing the cancellation.
const caller = new m.Task(ft, opts, inst, () => [], () => {});
const thread = new m.Thread(caller, (function* () {})());

// Subtask being cancelled, with a callee task that has not yet gone
// idle (so the determinacy park is entered) and an onCancel hook.
const st = new m.Subtask();
const i = inst.handles.add(st);
st.state = m.SubtaskState.STARTED;
const callee = new m.Task(ft, opts, inst, () => [], () => {});
callee.threads.push(new m.Thread(callee, (function* () {})()));
st.calleeTask = callee;
st.onCancel = () => {};

// Enter subtask.cancel (JSPI async form): it hits the determinacy
// park because the callee thread is not yet done and not yet parked.
const pending = m.withActivation(thread, () =>
  a.createSubtaskCancel({ async: true }, inst, "jspi")(i));
const result = pending.then(
  (value: unknown) => ({ value }),
  (e: unknown) => ({ error: String(e) }),
);

// Sibling: with hasSyncWaiter cleared at park entry, joining a
// waitable set on the same handle is accepted per definitions.py.
const set = new m.WaitableSet();
const si = inst.handles.add(set);
a.createWaitableJoin(inst)(i, si);

// Resolve the subtask and deliver its SUBTASK event.
st.resolve(m.SubtaskState.CANCELLED_BEFORE_RETURNED, []);
st.setSubtaskPendingEvent(i);

// The sibling consumes the resolution event first.
console.log("sibling event:", set.poll(caller, false));

// Callee threads finish -> determinate; cancellation continuation
// resumes on the next tick and tries to consume the SAME event.
callee.threads.length = 0;
store.tick();

console.log("cancel:", await result);
store.releasePendingOf(thread);
console.log("remaining waiters:", store.waiting.length);

Run:

cd runtime
deno run --config deno.json --allow-read repro_cancel_race.ts

Expected

Either:

• subtask.cancel's continuation observes that its event was already
  claimed by the sibling and reports a defined outcome (e.g. by
  retaining the claim through the determinacy wait, matching the sync
  form's behavior at line 467's own comment: "Sync cancellation retains
  the claim through its resolution wait, as in the reference"), or
• The sibling's waitable.join/poll is rejected while the cancellation
  claim is outstanding for this resolution.

In either case, the resolution event is consumed by exactly one waiter
and subtask.cancel never crashes.

Actual

sibling event: [ 1, 1, 4 ]
cancel: { error: "AssertionError: getPendingEvent with no pending event" }
remaining waiters: 0

The sibling's set.poll consumes the SUBTASK event first
(sibling event). The cancellation continuation then runs finish()
(async_builtins.ts:349), which calls st.getPendingEvent()
unconditionally since st.resolved() is true, and hits the
pendingEvent !== null assertion in
runtime/src/task/waitable.ts:62-65 — an internal AssertionError,
not a defined component-level trap.

Scope note

This reproduction drives the runtime's internal state machine directly
(Task/Subtask/WaitableSet/withActivation) rather than through a
compiled component, the same seam the existing
subtask_cancel_sync_waiter_window_test.ts uses. That's a deliberate
choice to isolate the two-consumer race precisely, not a claim that the
bug is unreachable from compiled wasm — hasSyncWaiter and
waitable.join's legality are checked by the async-lowering internals
regardless of caller.