Repository navigation
Async Hooks and Streams #33749
Description
Continuing a little bit from #33723.
Do we need closer integration between async hooks and streams? In particular since Stream.destroy can be invoked from basically anywhere the 'close' event can be emitted in a for user unexpected async scope (not sure yet about the correct terminology in async hooks context).
What currently seems to be the way to approach this is to monkey patch destroy after creating a stream, e.g.
const stream = new Duplex(...)
stream.destroy = asyncResource.runInAsyncScope.bind(asyncResource, stream.destroy, stream)Maybe would make sense to be able to provide a asyncId or asyncTriggerId (not sure of the difference yet) as a constructor argument?
Activity
addaleax commentedon Jun 5, 2020
I think it makes sense to first clarify whether we want to do something for EventEmitters in general, i.e. options 1 or 2 from #33723 (comment). I’ll re-open that issue.
ronag commentedon Jun 5, 2020
Yes, please.
jasnell commentedon Jun 5, 2020
EventEmitter is going to be a tricky one if only because of how performance sensitive it is. It absolutely makes sense for an EventEmitter to be tracked as an async resource but when I went through the exercise of making it one it ended up 2x-3x slower in regular use scenarios (streams, http servers, etc). I'm 100% in favor of doing something here but the performance loss problem absolutely needs to be addressed.
github-actions commentedon Jun 27, 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 Jul 28, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.