`AbortSignal.timeout()` may not abort past the timeout

[nstepien]

What is the issue with the DOM Standard?

When running synchronous code, signal.aborted does not become true after the expected timeout, signal.throwIfAborted() does not throw either.

This can be an issue in, for example, testing frameworks and lead to tasks never aborting if synchronous work keeps running.

I'd like to write code like this, but it's impossible as it stands:

const signal = AbortSignal.timeout(500);

while (!signal.aborted) {
  // perform work...
  task(signal);
}

Repro code:

const signal = AbortSignal.timeout(500);
const start = Date.now();
const timeout = start + 5000;

signal.addEventListener('abort', () => {
  console.log('signal aborted');
});

while (Date.now() < timeout) {
  // this should throw after 500ms
  signal.throwIfAborted();
}

console.error('this log should be unreachable');
console.log('signal.aborted:', signal.aborted);
console.log('elapsed:', Date.now() - start);
signal.throwIfAborted();

Result:

[juner]

@nstepien
As per the current spec you quoted, the abort steps are queued as a task. This means that as long as synchronous code keeps running without yielding, the task never gets a chance to run, and signal.aborted remains false.

Are you suggesting that AbortSignal.timeout() should update the aborted flag from outside the task queue (e.g. in parallel), so that it can be observed even during long-running synchronous execution?

[annevk]

You should probably queue tasks to perform your work as to not block the event loop. I could maybe see wanting to support this kind of flow in dedicated workers, but we'd probably want a dedicated API for that.

[nstepien]

Are you suggesting that AbortSignal.timeout() should update the aborted flag from outside the task queue (e.g. in parallel), so that it can be observed even during long-running synchronous execution?

Sort of, I wish .aborted was getter that would check if the signal timed out, likewise for throwIfAborted(), but it seems beyond the scope/intent of the original AbortSignal.
Maybe a new TimeoutSignal API with different semantics would be better?
I tried implementing a class TimeoutSignal extends AbortSignal, but that's not allowed it seems ("Illegal constructor").

Proxying a signal has its own issues too, it seems:

const signal = AbortSignal.timeout(500);
const proxiedSignal = new Proxy(signal, {});
// AbortSignal.any fails with
// Failed to execute 'any' on 'AbortSignal': Failed to convert value to 'AbortSignal'.
AbortSignal.any([proxiedSignal]);

You should probably queue tasks to perform your work as to not block the event loop.

That makes sense in general, until you pass your own signal to code you don't have control over, which may have a bug.

Even if you schedule your task carefully, it may be possible to pass a signal to a library which checks for signal.aborted without yielding to other tasks.

The opposite is also possible: the library gives you a signal, and you don't yield to the main thread to check if the signal is aborted, for example:

lib.performTask({
  task: fn,
  runCheck({ signal }) {
    // is it obvious that I must yield to the main thread first here?
    return !signal.aborted && condition;
  }
});

It's not necessarily about stopping infinite loops, some tasks may take longer than anticipated/desired.
Should I always yield to the main thread before reading .aborted?

[nstepien]

When trying out the exact example given in the spec: https://dom.spec.whatwg.org/#example-throwifaborted

async function waitForCondition(func, targetValue, { signal } = {}) {
  while (true) {
    signal?.throwIfAborted();

    const result = await func();
    if (result === targetValue) {
      return;
    }
  }
}

const signal = AbortSignal.timeout(500);

// ⚠️ this never aborts
await waitForCondition(
  async () => 1,
  2,
  { signal }
);

// ⚠️ yielding to the main thread, never aborts
await waitForCondition(
  async () => {
    await scheduler.yield();
    return 1;
  },
  2,
  { signal }
);

// ⚠️ postTask with 'user-blocking' priority, never aborts
await waitForCondition(
  async () => {
    await scheduler.postTask(() => {}, { priority: 'user-blocking', signal });
    return 1;
  },
  2,
  { signal }
);

// ✅ postTask with 'user-visible' or 'background' priority, the loop aborts after timeout is reached!
await waitForCondition(
  async () => {
    await scheduler.postTask(() => {}, { priority: 'user-visible', signal });
    return 1;
  },
  2,
  { signal }
);

// ⚠️ queueMicrotask, never aborts
await waitForCondition(
  async () => {
    await new Promise(queueMicrotask);
    return 1;
  },
  2,
  { signal }
);

Not all async tasks are created equal, so the AbortSignal.timeout() API is in my honest opinion not good enough as it stands, or should only be used with user-visible/background tasks.

[nstepien]

I checked the behavior of equivalent APIs in Node.js out of curiosity, and the behavior is a little bit better:

import { scheduler, setImmediate } from 'node:timers/promises';
import { styleText } from 'node:util';

async function runUntilTimeout(type, func) {
  console.time(type);

  const signal = AbortSignal.timeout(500);

  while (!signal.aborted) {
    try {
      await func(signal);
    } catch {
      console.log(styleText('red', 'error caught'));
      break;
    }
  }

  console.timeEnd(type);
}

// ✅ this aborts
// https://nodejs.org/api/timers.html#timerspromisesscheduleryield
await runUntilTimeout('yield', async () => {
  await scheduler.yield();
});

// ✅ this aborts
await runUntilTimeout('setImmediate', async () => {
  await setImmediate();
});

// ✅ setImmediate throws an error when the signal aborts
await runUntilTimeout('setImmediate with signal', async (signal) => {
  await setImmediate(undefined, { signal });
});

// ⚠️ this never aborts
await runUntilTimeout('queueMicrotask', async () => {
  await new Promise(queueMicrotask);
});