-
Notifications
You must be signed in to change notification settings - Fork 551
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Long-lived AbortSignals and undici cause MaxListenersExceededWarnings #3157
Labels
bug
Something isn't working
Comments
5 tasks
achingbrain
referenced
this issue
in ipfs/helia
Apr 22, 2024
Node's `undici` module appears to be adding listeners for the `"abort"` event on any passed AbortSignal but then not cleaning them up. This casues many `MaxListenersExceededWarning`s to appear in the console and likely causes a memory leak. To work around this, use a short-lived `AbortSignal` for each request that can be garbage collected along with the request itself. See https://github.com/nodejs/node/issues/52635 for more information.
3 tasks
achingbrain
referenced
this issue
in ipfs/helia
Apr 22, 2024
Node's `undici` module appears to be adding listeners for the `"abort"` event on any passed AbortSignal but then not cleaning them up. This casues many `MaxListenersExceededWarning`s to appear in the console and likely causes a memory leak. To work around this, use a short-lived `AbortSignal` for each request that can be garbage collected along with the request itself. See https://github.com/nodejs/node/issues/52635 for more information.
VoltrexKeyva
changed the title
Long-lived AbortSignals and unidici cause MaxListenersExceededWarnings
Long-lived AbortSignals and undici cause MaxListenersExceededWarnings
Apr 22, 2024
achingbrain
referenced
this issue
in ipfs/helia
Apr 22, 2024
Node's `undici` module appears to be adding listeners for the `"abort"` event on any passed AbortSignal but then not cleaning them up. This casues many `MaxListenersExceededWarning`s to appear in the console and likely causes a memory leak. To work around this, use a short-lived `AbortSignal` for each request that can be garbage collected along with the request itself. See https://github.com/nodejs/node/issues/52635 for more information.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version
v20.11.0
Platform
Darwin MacBook-Pro-194.localdomain 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000 arm64
Subsystem
undici
What steps will reproduce the bug?
Making multiple
fetch
requests with the sameAbortSignal
causesMaxListenersExceededWarning
s to appear in the console with a high number of listeners.If
undici
is adding event listeners without removing them, this is a memory leak.There is a repro repo here: https://github.com/achingbrain/node-fetch-maxlistenersexceededwarning
How often does it reproduce? Is there a required condition?
Every time. No required condition.
What is the expected behavior? Why is that the expected behavior?
Undici should remove any added event listeners when there is nothing left to abort (e.g. the request has ended and so either errored or the body has been consumed/cancelled).
What do you see instead?
Additional information
A workaround appears to be to create a request-specific signal and abort it if the long lived signal aborts, taking care to remove any added listeners on the long-lived signal when we are done with the request.
See: https://github.com/achingbrain/node-fetch-maxlistenersexceededwarning/blob/main/workaround.js
This may be a duplicate of nodejs/node#52203 - please close this issue if you consider it so, but the workaround above may be of use to someone if there's no way to get
undici
to clean up after itself.The text was updated successfully, but these errors were encountered: