The leak is one of the highest priorities. That said other things do come up and sometimes we have to react to them.
If the problem was in our agent, the fix would likely be very simple, but the problem exists in node core and makes it vastly more difficult to fix for a number of reasons. Part of that is having reproduction cases that meet cores standards. Currently there is a provable leak when you hit google.com but core would like a test that doesn’t involve hitting an external server. This means recording packets and timing and trying to replay as exactly as possible to show the problem using a node based TLS server, (only some TLS servers cause the race conditions)
Another part of it is, that the race condition involves both the
tls module and the
net module. Neither of which is particularly simple because it is a confluence of several duplex streams (which are really 2 different streams all with their own state). Plus a couple other state orchestration objects. I am working with core folks on this issue.
Just to reiterate: the issue is with node core, the agent is using all the APIs properly and not leaking the memory itself. In fact you can find cases of other libraries running into this bug (such as aws.js) they eventually stopped using custom certs on their outbound, which makes the leak much smaller, but still exists. We are considering going that route but there would still be a leak, just slower, and we have have a few reasons why we ship our own certs instead of trusting what node ships with.