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
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.
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.
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.
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.Maybe would make sense to be able to provide a
asyncId
orasyncTriggerId
(not sure of the difference yet) as a constructor argument?The text was updated successfully, but these errors were encountered: