[memory leak] Sockets / streams: end() / final() vs destroy() - which one cleans up the stream?

[theogravity]

I noticed that destroy() was added in node 8.

After reading through the docs for both, I'm not entirely clear which I should be calling, especially if I'm concerned about memory leaks.

destroy() seems to do some extra stuff, including triggering the error event if an error is defined.

It also seems that I should be using destroy() when I'm using duplex streams once I'm completely done with the stream in general (eg I'm done with both the read/write side, it's better than having to remember to call end()/final() individually.)

I'm asking with respect to generic streams, but also when using http.ClientRequest (do I need to call it in the res object after I get the end event from the server?).

[gireeshpunathil]

from memory leak perspective, there are at least 2 angles to it:

1. leak of data held in the socket / stream
2. leak of objects abstracted by socket / stream

for 1, I guess end or destroy both solve the purpose, the underlying resource is detached and closed, so no data gets clogged

for 2, neither end nor destroy will be sufficient, the object that represent the socket or stream should go out of scope of get garbage collected.

this is my theory, I have not tested it. /cc @nodejs/streams for an expert opinion.

[mcollina]

I would recommend using .destroy() for dealing with error conditions.

Overall, you should be using stream.pipeline or pump most of the time. destroy() is needed for these to work well.

[gireeshpunathil]

closing as answered.