`parallel/test-without-async-context-frame` is flaky (time out)

[richardlau]

Test

parallel/test-without-async-context-frame

Platform

macOS x64, Linux x64

Console output

not ok 4181 parallel/test-without-async-context-frame
  ---
  duration_ms: 120111.00200
  severity: fail
  exitcode: -15
  stack: |-
    timeout
  ...

Build links

• https://ci.nodejs.org/job/node-test-commit-osx/nodes=macos15-x64/67359/console
• https://ci.nodejs.org/job/node-test-commit-linux-containered/nodes=ubuntu2404_sharedlibs_shared_x64/53117/console
• https://ci.nodejs.org/job/node-test-commit-linux-containered/nodes=ubuntu2404_sharedlibs_shared_x64/53105/console
• https://ci.nodejs.org/job/node-test-commit-osx/nodes=macos15-x64/67253/console

Additional information

According to

• CI Reliability 2025-10-15 reliability#1349
• https://github.com/nodejs/reliability/blob/main/reports/2025-10-15.md

this is failing for 17 PRs in the most recent 100 CI runs.

The tests appear to be hitting the 2 minute default timeout. This looks like a different failure than that previously seen on Windows (crash) in #56751.

[joyeecheung]

The test looks a bit odd, it spends a lot of time trying to look for suitable tests from the async-hooks and parallel directory then use tools/test.py to run them. This may be troublesome on slower machines. A better implementation would be to move test/parallel/test-async-local-storage-* into test/async-hooks, and then in test/async-hooks/testcfg.py, override ListTests of ParallelTestConfiguration so that it enqueues an additional test with the --no-async-context-frame appended to additional_flags, so the python test runner would handle the timeout separately and correctly parallelize the tests.

cc @Qard

[joyeecheung]

Or at the very least, that test could just simply spawn tools/test.py */test-async-local-storage-* instead of trying to run the tests one by one. The python test runner supports wildcards, so there's no need to do the matching in that test.

[Qard]

I was thinking at one point it'd be nice to just have support for multiple Flags lines running the test multiple times with each set. That'd be a nice solution.

Either way, yeah...bundling all the single tests into one big test is not ideal, but I didn't want to duplicate them all and have them get out-of-sync. They need to validate the function the same.

[joyeecheung]

I opened #60273 to at least parallelize it correctly using the wildcard of test.py. This is at least much faster on my macbook (it'll probably be a bit even faster with #60266)