Is it possible to test the sync-vs-async issue, or is that hidden behind other machinery?

Is it possible to test the sync-vs-async issue, or is that hidden behind other machinery?

I think that's all behind internal machinery. The first observable thing that happens after aborting the signal is the streams becoming unlocked (readable.locked === false && writable.locked === false) and the pipe promise getting rejected.

I suppose you could count how many micro-ticks have passed between those two events with something like:

const controller = new AbortController();
readable.pipeTo(writable, { preventCancel: true, preventAbort: true, signal: controller.signal });
controller.abort();

let microTicks = 0;
while (readable.locked) {
  await Promise.resolve();
  microTicks++;
}

However, the current spec doesn't require any precise number of micro-ticks. For example: step c in "shutdown with an action" says to "wait until every chunk that has been read has been written". If there are no pending writes, then it should be feasible to continue the steps synchronously. But even the reference implementation adds one micro-tick in that case because it uses .then() (source).

I don't think it's worth dictating the amount of micro-ticks that it should take to shutdown the pipe. Perhaps some browser can do it with fewer micro-ticks because of clever optimizations for special streams. Or some browser may need additional round-trips to figure out whether there are still pending writes. As long as the pipe eventually shuts down properly, I think both implementations should be valid. 🙂

Agreed, it's always been an anti-goal to constrain the number of micro-ticks. In that case I'm happy to merge.