Possible memory leak in nodejs interception

[mathanpec]

Describe the bug

A clear and concise description of what the bug is.

I have a simple repo with 16 test files where every test file does the same thing of firing a simple fetch call and asserting for the response from the MSW handler. But when we run all the test files one after the other the heap usage keeps increasing. But when I comment the MSW server instantiation and other MSW related code heap memory stays constant.

Environment

• msw: 0.28.2
• nodejs: v12.14.0
• npm: 6.13.4

Please also provide your browser version.

To Reproduce

Steps to reproduce the behavior:

1. Clone the repo https://github.com/mathanpec/msw-memory-leak-test
2. Do yarn install
3. Execute node --expose-gc ./node_modules/.bin/jest --silent --runInBand --detectOpenHandles --logHeapUsage
4. I am specifically doing node --expose-gc and running GC in the AfterAll step to make sure there are no unused memory is left between test files.

Expected behavior

Memory heap should be consistent between every file runs or there should be a very minimal change. Check the following screenshot from the same repo without MSW server initialisation and handlers

[kettanaito]

Thank you for reporting this, @mathanpec!

Please, do you have any insights as to where the memory heap originates from within MSW? Any help on this matter is highly appreciated.

[marcosvega91]

I have experienced the same issue some time ago when I was testing monkey patching.

[mathanpec]

Hi @kettanaito,

So I tried profiling the runs and this is what I could find,

You can see ClientRequestOverride is being referenced recursively and when I looked at the code, http.ClientRequest is being monkey patched here but its not being set back to the original reference anywhere. This could be one possible cause but I am not very sure though.

[kettanaito]

That's a great observation, @mathanpec! I've opened a related issue in the interceptors repository. I think the fix should be straightforward—restore the patched version to the already stored original class.

Please, would you be interested in making such a pull request happen?

[mathanpec]

Hi @kettanaito,

I did try restoring the patch version to the already stored original class. But still I am seeing heap memory is increasing consistently as shown in the image below though previous recursive ClientRequestOverride is not showing up in the heap profile run.

And in the heap profile I couldn't find anything recursive now but I could see multiple copies of the same msw index file in memory as shown below. But I am not sure whether it is very relevant to the issue.

[mathanpec]

Hi @kettanaito,

As mentioned in this issue comment, I tried removing the monkey patching of clientRequest completely in the interceptor library and after that my heap memory usage stays constant now as in the below image,

PR for the same: mswjs/interceptors#116

[mathanpec]

Hi @kettanaito,

Can you pls take a look into this and let me know your thoughts on this?

[kettanaito]

Hey, @mathanpec. I've commented on the pull request. Will have to check it out and get back to you. Thank you for your work on this, it looks great!

[mathanpec]

Hi @kettanaito,

Thanks for looking into this and closing on this :) And Thanks a lot for this excellent library.

Also would be able to tell approximately when can we expect this fix to get released?

[kettanaito]

Thank you for the contribution, @mathanpec!
This fix should be released alongside #688, as both introduce breaking changes and I'd like to get it into a single minor version bump. Hope to get that done by the end of the month.