MaxListenersExceededWarning when using beforeEach or afterEach in test runner tests

[ForbiddenEra]

Version

20.4.0

Platform

Linux ubuntu.wsl2 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

test runner

What steps will reproduce the bug?

Running this code will cause two warnings (one each for beforeEach and afterEach)

import test from 'node:test';

(async()=>{
    await test(`MAIN`, async(t) => {
        /*
          just using 'beforeEach' or 'afterEach' causes the event emitter warning on the 11th test in this suite,
          if you don't call either to assign a callback to run before/after each test, then no warning occurs
        */
        t.beforeEach(()=>{});
        t.afterEach(()=>{});

        await t.test('1', async(t) => {
            await t.test('a', async() => {});
            await t.test('b', async() => {});
        });

        await t.test('2', async(t) => {
            await t.test('a', async() => {});
            await t.test('b', async() => {});
            await t.test('c', async() => {});
            await t.test('d', async() => {});
            await t.test('e', async() => {});
        });

        await t.test('3', async(t) => {
            await t.test('a', async() => {});
            await t.test('b', async() => {});
        });

        await t.test('4', async(t) => {
            await t.test('a', async() => {});
            await t.test('b', async() => {});
        });

    });
})();

How often does it reproduce? Is there a required condition?

Anytime you've started more than 10 tests in a test suite using either/both beforeEach/afterEach

What is the expected behavior? Why is that the expected behavior?

No warnings? I would've assumed any listeners should be removed after each test finishes.

What do you see instead?

With --trace-warnings, running the above code, I get this error/stacktrace:

(node:7277) MaxListenersExceededWarning: Possible EventTarget memory leak detected. 11 abort listeners added to [AbortSignal]. Use events.setMaxListeners() to increase limit
    at [kNewListener] (node:internal/event_target:546:17)
    at [kNewListener] (node:internal/abort_controller:238:24)
    at EventTarget.addEventListener (node:internal/event_target:659:23)
    at eventTargetAgnosticAddListener (node:events:1028:13)
    at node:events:985:5
    at new Promise (<anonymous>)
    at once (node:events:965:10)
    at stopTest (node:internal/test_runner/test:79:12)
    at TestHook.run (node:internal/test_runner/test:558:27)
    at TestHook.run (node:internal/test_runner/test:759:18)
(node:7277) MaxListenersExceededWarning: Possible EventTarget memory leak detected. 11 abort listeners added to [AbortSignal]. Use events.setMaxListeners() to increase limit
    at [kNewListener] (node:internal/event_target:546:17)
    at [kNewListener] (node:internal/abort_controller:238:24)
    at EventTarget.addEventListener (node:internal/event_target:659:23)
    at eventTargetAgnosticAddListener (node:events:1028:13)
    at node:events:985:5
    at new Promise (<anonymous>)
    at once (node:events:965:10)
    at stopTest (node:internal/test_runner/test:79:12)
    at TestHook.run (node:internal/test_runner/test:558:27)
    at TestHook.run (node:internal/test_runner/test:759:18)

Additional information

I likely would've noticed this earlier than now, however my test script was using --no-warnings because the node:test test runner suite was experimental at the time I started building the tests, --no-warnings wasn't removed from my script once it was marked stable in 20.0.0 yet but was looking deeper into some bugs of my own and ran my tests directly without --no-warnings and saw this.

I haven't tested this issue on 20.5.0 yet but I did do a quick but fruitless search through issues to see if it had been discussed previously.

[cjihrig]

I believe this is a duplicate of #48475, which is fixed on main but not yet released.

[ForbiddenEra]

I believe this is a duplicate of #48475, which is fixed on main but not yet released.

Must have missed that, seems to be the case. Thanks!