You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Clear kResourceStore in timers and intervals #53408
As noted in this article, the timeout/interval objects keep a reference to the store even after they have been cleared.
I think it would be better to clear up that reference inside the clearTimeout() and clearInterval() functions. We might also want to consider exposing an API for end-users and explicit lifetime tracking.
setTimeout should probably actually just clear immediately after running given that it only occurs once. But yes, also clearing in clearInterval makes sense to me too.
Reacted by Benjamin Gruenbaum, Jacob Morrison, Yagiz Nizipli, Matteo Collina, jakecastelli, Abhijeet Prasad and Ruben Bridgewater
I guess this is not only relevant for timers and intervals, all resources are effected.
const{ AsyncLocalStorage, AsyncResource }=require('node:async_hooks');constals=newAsyncLocalStorage();letr,p;als.run("I consume a lot memory",()=>{r=newAsyncResource("aResource",{requireManualDestroy: true})r.emitDestroy()p=Promise.resolve()})console.log(r,p);
AsyncResource { [Symbol(async_id_symbol)]: 2, [Symbol(trigger_async_id_symbol)]: 1, [Symbol(kResourceStore)]: 'I consume a lot memory'} Promise { undefined, [Symbol(async_id_symbol)]: 3, [Symbol(trigger_async_id_symbol)]: 1, [Symbol(kResourceStore)]: 'I consume a lot memory'}
For timers/intervals it's likely easier to find the place to cleanup.
Maybe we can extend the cleanup to some more places?
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Activity
mcollina commentedon Jun 10, 2024
cc @nodejs/diagnostics @anonrig
Qard commentedon Jun 10, 2024
setTimeoutshould probably actually just clear immediately after running given that it only occurs once. But yes, also clearing inclearIntervalmakes sense to me too.Flarna commentedon Jun 11, 2024
I guess this is not only relevant for timers and intervals, all resources are effected.
For timers/intervals it's likely easier to find the place to cleanup.
Maybe we can extend the cleanup to some more places?
mcollina commentedon Jun 11, 2024
Absolutely!
Flarna commentedon Jun 28, 2024
timers allow similar "leaks" even without AsyncLocalStore if one uses arguments for the handler:
If handler uses some variable from the outer scope it's even more.
github-actions commentedon May 20, 2026
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
github-actions commentedon Jun 19, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
timers: do not retain a reference to the async store after firing
timers: do not retain a reference to the async store after firing
timers: do not retain a reference to the async store after firing
timers: do not retain a reference to the async store after firing
timers: do not retain a reference to the async store after firing
timers: do not retain a reference to the async store after firing
Errorcreated inside asetImmediatecallback retains theImmediate, its AsyncLocalStorage store, and — via stale_idleNext/_idlePrevlinks — the stores of every Immediate that ran in the same tick #66129 as a duplicate of this issue