`MockHttpSocket` and `MockHttpAgent` are not being garbage collected

[rossipedia]

Prerequisites

• I confirm my issue is not in the opened issues
• I confirm the Frequently Asked Questions didn't contain the answer to my issue

Environment check

• I'm using the latest msw version
• I'm using Node.js version 18 or higher

Node.js version

22.12.0

Reproduction repository

https://github.com/rossipedia/msw-leak-test

Reproduction steps

Instructions are in the reproduction repo, but they are essentially:

1. clone repro
2. npm install
3. ./demo.sh

Current behavior

Note

This is a follow up to my colleague's issue #2390

Enabling MSW with no handlers and then load-testing using ab causes heap usage to balloon, even when manually invoking garbage collection.

As best I can tell, the largest percentage of retained objects are primarily:

• MockHttpSocket
• MockHttpAgent

I do not believe this is related to express, as only ClientRequest is intercepted, and I don't think express or http.createServer use ClientRequest, only IncomingMessage and ServerResponse (I could be wrong about that though).

Expected behavior

Memory usage should be stable under load when simply enabling MSW in a node application.

[mikeparker]

This is causing a large memory leak meaning we have to restart our production pods every day. Any update / acknowledgement of the issue would be great.

[mikeparker]

@kettanaito sorry for the direct ping and we really appreciate your work here, but this is causing us at Docker significant issues as use MSW in production to host a demo environment that matches our e2e tests and we have to restart production pods constantly due to this MSW memory leak.

We can potentially contribute engineering effort if you can help point us in the right direction as it would be a large lift to migrate away from MSW for this.

[kettanaito]

@mikeparker, I am sorry to hear that this is blocking you. If you have time, could you please see what in MockHttpSocket causes it to persist?

My initial guess is that it can be request or response parser, although we try to free it at the first available moment (1, 2).

I will try to look into this but I am overburdened as of now. I would be grateful if you landed me a hand investigating this so I can roll out the appropriate fix as soon as we know what's causing the issue. Thanks.

[kettanaito]

Another potential problem area is that the agent/socket interface may not have some of the methods implemented that result in it not being disposed of correctly. This can be proven/disproven by constructing and observing an actual net.Socket to see what gets called in your particular use case (debugger or Proxy are useful for this).

[85B622ACA6]

I think I'm seeing something related:
https://gist.github.com/85B622ACA6/48b57fe7c595522f3957e40d1392adc7

It would be nice to be able to use msw without the websocket interceptors being applied.

[kettanaito]

@85B622ACA6, I don't believe we interfere with request at that level to result in the unexpected destroy() there. It may be a side effect of our implementation but I fail to see how it can result in a memory leak.

[85B622ACA6]

I believe you are correct. After playing around with it some more, the results I was seeing seem to be related to how msw interacts with the 'ws' WebSocket client.

I hate to go of topic, but is msw expected to play nicely with clients from the 'ws' package?

[kettanaito]

I've opened a pull request to try to measure the memory footprint of the interceptors in mswjs/interceptors#702. While I cannot see quite the same memory heap given more-or-less the same reproduction scenario, the memory snapshot with interceptors is ~50MB larger for 10,000 requests.

Alas, I have no idea how to navigate the heap snapshot to understand why MockHttpSocket (and the agent) aren't disposed of.

[kettanaito]

I hate to go of topic, but is msw expected to play nicely with clients from the 'ws' package?

Yes, I believe so. We are using ws extensively for server-side testing so I'd expect it to work with ws client as well, given they implement the same logic. MSW supports anything that relies on the global WebSocket API.