fetch/api/abort/general.any.js WPT is flaky on Windows

[KhafraDev]

fetch/api/abort/general.any.js has a test that occasionally prevents the worker from exiting, causing the CI to fail after it times out. This file is a conglomerate of ~50 tests, so skipping the file entirely is not a feasible solution. There is no way to disable individual tests either since undici uses the WPT test harness.

The test is only flaky on windows, and is most likely an issue where something isn't getting unref'd (considering it's testing aborts, it's likely AbortController/AbortSignal). Using powershell, you can run the wpt testing script x amount of times by doing 1..50 | % { npm run test:wpt }

It's possible to determine when a test times out using the following diff:

diff --git a/test/wpt/runner/runner/runner.mjs b/test/wpt/runner/runner/runner.mjs
index 8dfb21e8..a99b94fc 100644
--- a/test/wpt/runner/runner/runner.mjs
+++ b/test/wpt/runner/runner/runner.mjs
@@ -112,6 +112,13 @@ export class WPTRunner extends EventEmitter {
       })

       activeWorkers.add(worker)
+      const timeout = setTimeout(
+        () => {
+          console.log('test timed out', { worker, test })
+        },
+        meta.timeout === 'long' ? 60_000 : 10_000
+      )

       worker.on('message', (message) => {
         if (message.type === 'result') {
@@ -123,6 +130,7 @@ export class WPTRunner extends EventEmitter {

       worker.once('exit', () => {
         activeWorkers.delete(worker)
+        clearTimeout(timeout)

         if (activeWorkers.size === 0) {
           this.handleRunnerCompletion()

Calling worker.terminate doesn't do anything in this case because there may still be active refs; terminate works "as soon as possible". Another option is to send a message to the worker, and force it to shutdown, but there may be other implications by doing this.

[KhafraDev]

This test is the test causing issues:

test.js

promise_test(async t => {
  await abortRequests();

  const controller = new AbortController();
  const signal = controller.signal;
  const stateKey = token();
  const abortKey = token();
  requestAbortKeys.push(abortKey);

  const response = await fetch(`../resources/infinite-slow-response.py?stateKey=${stateKey}&abortKey=${abortKey}`, { signal });
  const reader = response.body.getReader();

  await reader.read();

  controller.abort();

  await promise_rejects_dom(t, "AbortError", reader.read());
  await promise_rejects_dom(t, "AbortError", reader.closed);

  // The connection won't close immediately, but it should close at some point:
  const start = Date.now();

  while (true) {
    // Stop spinning if 10 seconds have passed
    if (Date.now() - start > 10000) throw Error('Timed out');

    const afterAbortResult = await fetch(`../resources/stash-take.py?key=${stateKey}`).then(r => r.json());
    if (afterAbortResult == 'closed') break;
  }
}, "Stream errors once aborted, after reading. Underlying connection closed.");

Everything in the while loop is irrelevant to us. If it was being reached, the test would throw an error. So, the logical conclusion is that there is an issue in the infinite-slow-response.py route. This route relies on timers, which are known to cause issues (and seems to have caused the flakiness). Upping the delay to 100ms (10x that of the python WPT server), the flakiness stops locally.