AbortSignal.any() causes memory leak

Version

v22.6.0

Platform

Microsoft Windows NT 10.0.22631.0 x64
Linux ****** 4.4.0-22621-Microsoft #3672-Microsoft Fri Jan 01 08:00:00 PST 2016 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

https://nodejs.org/api/globals.html#class-abortsignal

What steps will reproduce the bug?

Run this and watch memory usage.

const formatMemoryUsage = (data) => `${Math.round(data / 1024 / 1024 * 100) / 100} MB`;

let memoryData = process.memoryUsage();
console.log('Mem before loop', formatMemoryUsage(memoryData.rss));

for (let i = 0; true; i++) {
    const abortController = new AbortController();
    const signal = abortController.signal;
    const composedSignal = AbortSignal.any([signal]);

    if (i === 1000000) {
        break;
    }
}

memoryData = process.memoryUsage();
console.log('Mem after 1 million iteration', formatMemoryUsage(memoryData.rss));

This is what I get on my local machine

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

Always reproducible as far as I can tell

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

Memory post loop execution should be fairly equivalent to the first log but somehow the const composedSignal = AbortSignal.any([signal]); does not get cleaned up from memory, I would expect this to get cleaned properly or if this is the intended behavior to have a clear warning in the documentation.

What do you see instead?

We see a memory leak that will eventually lead to an out of memory error.

Additional information

This has been tested on Node 22.6 on different machine and both Windows + Unix versions. Happy to provide more details if needed

This might (I'm not sure) be a duplicate of #48419

$ node repro.js 
Mem before loop 44.25 MB
Mem after 1 million iteration 1375.11 MB

I started taking some snapshot

@redyetidev would you have any clue?

I think the issue here is that everything is happening in the same tick. This does not leak for me:

const formatMemoryUsage = (data) => `${Math.round((data / 1024 / 1024) * 100) / 100} MB`;

let memoryData = process.memoryUsage();
console.log('Mem before loop', formatMemoryUsage(memoryData.rss));

let i = 0;
function run() {
    const abortController = new AbortController();
    const signal = abortController.signal;
    const composedSignal = AbortSignal.any([signal]);

    if (i === 1000000) {
        memoryData = process.memoryUsage();
        console.log('Mem after 1 million iteration', formatMemoryUsage(memoryData.rss));
    } else {
        i++;
        setImmediate(run);
    }
}

run();

I find that if you combine an abort signal inside the loop with one outside, you still get the problem although not quite as severely.

const formatMemoryUsage = data =>
  `${Math.round((data / 1024 / 1024) * 100) / 100} MB`;

let memoryData = process.memoryUsage();
console.log('Mem before loop', formatMemoryUsage(memoryData.rss));

const otherAbortController = new AbortController();

let i = 0;
function run() {
  const abortController = new AbortController();
  const signal = abortController.signal;
  const composedSignal = AbortSignal.any([signal, otherAbortController.signal]);

  if (i === 1000000) {
    memoryData = process.memoryUsage();
    console.log(
      'Mem after 1 million iteration',
      formatMemoryUsage(memoryData.rss),
    );
  } else {
    i++;
    setImmediate(run);
  }
}

run();

Mem before loop 36.91 MB
Mem after 1 million iteration 797.81 MB

Even if the other abort signal is inside the loop it still ends up using more.

const formatMemoryUsage = data =>
  `${Math.round((data / 1024 / 1024) * 100) / 100} MB`;

let memoryData = process.memoryUsage();
console.log('Mem before loop', formatMemoryUsage(memoryData.rss));

for (let i = 0; true; i++) {
  await new Promise(resolve => {
    const otherAbortController = new AbortController();
    const abortController = new AbortController();
    const signal = abortController.signal;
    const composedSignal = AbortSignal.any([
      signal,
      otherAbortController.signal,
    ]);
    setImmediate(() => {
      resolve();
    });
  });

  if (i === 1000000) {
    break;
  }
}

memoryData = process.memoryUsage();
console.log('Mem after 1 million iteration', formatMemoryUsage(memoryData.rss));

Mem before loop 36.88 MB
Mem after 1 million iteration 137.63 MB

node --version
v22.13.0

Weirdly I find the implementation in graphql-hive/gateway#922 resolves this in practical use, but in this test it doesn't seem to help much.

I've written a test file that demostrates various variations of this bug:

import * as process from 'node:process';
import { strict } from 'assert';

const iterations = 300_000;
describe('Test memory leak in abort controller', () => {
    let before: bigint;
    beforeEach(() => {
        before = BigInt(process.memoryUsage().rss) / 1024n / 1024n;
    });

    afterEach(() => {
        const after = BigInt(process.memoryUsage().rss) / 1024n / 1024n;
        // Memory should not have increased by more than 10MB:
        strict.ok(after < before + 100n, `before: ${before}, after: ${after}`);
    });

    // These don't work
    test('AbortSignal.any with only AbortController', async () => {
        const abortController = new AbortController();
        for (let i = 0; i < iterations; i++) {
            const signal = abortController.signal;
            AbortSignal.any([signal]);
        }
    });
    test('AbortSignal.any with AbortController and timeout', async () => {
        const abortController = new AbortController();
        for (let i = 0; i < iterations; i++) {
            const signal = abortController.signal;
            const timeout = AbortSignal.timeout(1);
            AbortSignal.any([signal, timeout]);
        }
    });
    test('AbortSignal.any with only timeout', async () => {
        for (let i = 0; i < iterations; i++) {
            const timeout = AbortSignal.timeout(1);
            AbortSignal.any([timeout]);
        }
    });
    test('AbortSignal.timeout', async () => {
        for (let i = 0; i < iterations; i++) {
            AbortSignal.timeout(1);
        }
    });

    // These work!
    test('AbortSignal.abort', async () => {
        for (let i = 0; i < iterations; i++) {
            AbortSignal.abort('hello');
        }
    });
    test('AbortSignal.any with nothing', async () => {
        for (let i = 0; i < iterations; i++) {
            AbortSignal.any([]);
        }
    });
});

We’ve run into the same pattern in a real long-running production workload (Lodestar beacon-node req/resp networking).

In our case, each req/resp round-trip composed a request abort signal with a response-timeout signal. Over time, those composed signals accumulated in the networking worker and showed up as steady old-space growth in heap snapshots.

The important part is that this was not a tight same-tick synthetic loop — it was normal long-lived request/response traffic on a running node.

Our mitigation on the application side was to stop using AbortSignal.any(...) for that path and instead manually compose the signals with explicit listener cleanup once the response stream closes. That change is here:

fix(reqresp): clear composed response timeout signals ChainSafe/lodestar#9029

So from our side, this issue is not just microbenchmark-only — we hit the same retention shape in a real networking path.

docs(reqresp): add upstream issue reference to createRespSignal

docs(reqresp): add upstream issue reference to createRespSignal (#9033)

lib: defer AbortSignal.any() following

fix(webapp): named sentinel abort reasons + cite Node issues

fix(webapp): eliminate SSE abort-signal memory leak (#3430)

chore: release v4.4.5 (#3406)

lib: defer AbortSignal.any() following

@AlexGilleranGP

Seems node 26.1.0 does not have this issue, similar script to @AlexGilleranGP

const formatMemoryUsage = data =>
  `${Math.round((data / 1024 / 1024) * 100) / 100} MB`;

let memoryData = process.memoryUsage();
console.log('Mem before loop', formatMemoryUsage(memoryData.rss));

const otherAbortController = new AbortController();

let i = 0;
function run() {
  const abortController = new AbortController();
  const signal = abortController.signal;
  const composedSignal = AbortSignal.any([signal, otherAbortController.signal]);

	if (i === 1000000) {
		for (let i = 0; i < 10; i++) {
			gc({ type: 'major' })
		}
    memoryData = process.memoryUsage();
    console.log(
      'Mem after 1 million iteration',
      formatMemoryUsage(memoryData.rss),
    );
  } else {
    i++;
    setImmediate(run);
  }
}

run();

On Node 26.1.0:

Mem before loop 48.44 MB
Mem after 1 million iteration 56.45 MB

On Node 25.9.0:

Mem before loop 47.19 MB
Mem after 1 million iteration 788.72 MB

Hi, guys. Here is our fix for this problem:

export const anySignal = (signals) => {
    const controller = new AbortController();
    const already = signals.find(s => s.aborted);    
    if (already) {
      controller.abort(already.reason);
    } else {
      for(const signal of signals) {
        const ref = new WeakRef(controller);
        const listener = () => ref.deref()?.abort(signal.reason);
        signal.addEventListener('abort', listener, { once: true });
        cleanupCallback.register(controller, ()=>signal.removeEventListener('abort', listener));
      }
    }
    return controller.signal;
};

const cleanupCallback = new FinalizationRegistry((callback) => callback());

// you can apply the monkey-patch if you are brave enough
// AbortSignal.any = anySignal;

Note: not needed on Node 26 — we confirmed the leak is already gone there.

Thanks for sharing this. From the Lodestar side, this does not change our current mitigation yet.

We still target Node ^24.13.0, so we need the application-side workaround until our runtime baseline moves to a Node version with the fix. In the req/resp path that hit this in production, Lodestar already stopped using AbortSignal.any(...) and now composes the parent signal + timeout signal with explicit listener cleanup when the response stream closes:

Your WeakRef / FinalizationRegistry approach looks useful as a drop-in any() workaround for callers that cannot deterministically know when the composed signal is no longer needed. For our req/resp case, the explicit clear() is still simpler because stream close gives us an exact cleanup point, and I would avoid monkey-patching global AbortSignal.any in Lodestar.

The Node 26 confirmation is useful, though. Once Lodestar's minimum runtime moves past the fixed Node line, this workaround should become removable rather than something we need to replace with a weak-listener polyfill.

I've written a test file that demostrates various variations of this bug:

See #54614 (comment) for the code.

The first of these tests works on 26.7 (it fails on 24.15), the rest still succeeds/fails as indicated in the code.

Navigation Menu

Repository navigation

AbortSignal.any() causes memory leak #54614

Version

Platform

Subsystem

What steps will reproduce the bug?

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

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

What do you see instead?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

AbortSignal.any() causes memory leak #54614

Description

Version

Platform

Subsystem

What steps will reproduce the bug?

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

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

What do you see instead?

Additional information

Activity

kallerosenbaum commented on Aug 28, 2024

avivkeller commented on Aug 28, 2024

geeksilva97 commented on Sep 25, 2024

mika-fischer commented on Oct 10, 2024

AlexGilleranGP commented on May 29, 2025

kallerosenbaum commented on Sep 5, 2025

lodekeeper commented on Mar 13, 2026

khalidsaidi commented on Mar 25, 2026

adiwajshing commented on May 14, 2026

DmitryGolovin-azur commented on Jul 28, 2026

lodekeeper commented on Jul 28, 2026

kallerosenbaum commented on Aug 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions