Request signal isn't aborted after garbage collection

Bug Description

Passing a signal to Request() and aborting it does not cause the underlying request signal to be aborted after it's been garbage collected. This leads to issues where you want to listen on the request signal even after the request itself falls out of scope - e.g., the request is instantiated with an abort controller signal and downstream code is waiting for that signal to be aborted via request.signal.

Reproducible By

Run the following using node --expose-gc main.js:

const ac = new AbortController();

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

const request = new Request("https://google.ca", { signal: ac.signal });

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

setTimeout(() => {
  global.gc();
  ac.abort();
}, 0);

Expected Behavior

ac signal aborted and request signal aborted should be logged to the console.

Instead, only ac signal aborted is logged.

Environment

Latest node and undici. Tried it in some older versions as well.

Additional context

A few folks are running into this while trying to close event stream requests in the remix web framework. The underlying requests are never closed because the signal doesn't get aborted.

@KhafraDev

@KhafraDev

https://dom.spec.whatwg.org/#abort-signal-garbage-collection

Therefore undici seems to be working properly? Since the parent AbortSignal is aborted, the dependent signal (ie. the one created for every instance of Request) can be garbage collected.

@KhafraDev

@KhafraDev - I would expect the dependent signal to also be aborted after the parent signal is aborted & before it is garbage collected. Currently, the dependent signal seems to stop working when the request itself is garbage collected, not when its parent signal is garbage collected. Perhaps I'm missing something?

Currently when a Request is collected, the signal is removed (see nodejs/undici#1113)

must not be garbage collected while its source signals is non-empty and it has registered event listeners for its abort event or its abort algorithms is non-empty.

There is a bug here - we shouldn't be removing the signal if there are registered 'abort' event listeners. I will have a PR in a few hours unless the approach I'm thinking of doesn't work.

I believe this is a bug in node -

const ac = new AbortController();

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

const request = {
  signal: (() => {
    const ourAc = new AbortController()
    ourAc.signal.addEventListener('abort', () => console.log('called'), { once: true })
    return ourAc.signal
  })()
}

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

setTimeout(() => {
  global.gc();
  ac.abort();
}, 0);

Only ac signal aborted is printed.

@benjamingr

@benjamingr

cc @nodejs/web-standards

transferred to node

Is there any work being done to resolve this?

@zachrip

@zachrip not at the moment, it's a bug in Node.js. Specifically https://dom.spec.whatwg.org/#abort-signal-garbage-collection is not implemented.

@KhafraDev

I believe this is a bug in node -
code here
Only ac signal aborted is printed.

@KhafraDev After GC removed the object request, the value of member signal will be removed by GC too.

@mcollina

node/deps/undici/src/lib/web/fetch/request.js

Line 431 in e775989

const acRef = new WeakRef(ac)

As I went through the implementation, I wanted to know whether this particular line is resulting in signal to be removed by GC or not.
@mcollina @KhafraDev @ronag

fix(webapp): fix Redis connection leak in realtime streams and broken…

fix(webapp): use getRequestAbortSignal() for dashboard stream routes

chore: release v4.4.5 (#3406)

fix(webapp): use getRequestAbortSignal() for dashboard stream routes

fix: replace SDK AbortSignal.timeout with application-level AbortCont…

chore: bump umm-actually to v0.3.9 (#453)

chore: bump umm-actually to v0.3.9 (#11)

Navigation Menu

Repository navigation

Request signal isn't aborted after garbage collection #55428

Bug Description

Reproducible By

Expected Behavior

Environment

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Request signal isn't aborted after garbage collection #55428

Description

Bug Description

Reproducible By

Expected Behavior

Environment

Additional context

Activity

ronag commented on Sep 26, 2024

ronag commented on Sep 26, 2024

KhafraDev commented on Sep 26, 2024

jvaill commented on Sep 26, 2024

KhafraDev commented on Sep 26, 2024

KhafraDev commented on Sep 27, 2024

ronag commented on Sep 27, 2024

mcollina commented on Sep 28, 2024

mcollina commented on Oct 17, 2024

zachrip commented on Dec 20, 2024

mcollina commented on Jan 14, 2025

Tseian commented on Mar 13, 2026

SudhansuBandha commented on Apr 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions