Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calling nock.restore() after each test suite doesn't stop memory leak #2077

Closed
yuchenQ opened this issue Aug 24, 2020 · 8 comments
Closed

Calling nock.restore() after each test suite doesn't stop memory leak #2077

yuchenQ opened this issue Aug 24, 2020 · 8 comments
Labels

Comments

@yuchenQ
Copy link

yuchenQ commented Aug 24, 2020

What is the expected behavior?

Hi there, I am a jest user.

  beforeEach(() => {
    if (!nock.isActive()) {
      nock.activate();
    }
  });

  afterEach(() => {
    nock.cleanAll();
    nock.restore();
  });

calling this block should stop memory leak.

What is the actual behavior?

When I checkout the heap size usage by running node --expose-gc ./node_modules/.bin/jest --runInBand --logHeapUsage <DIR>
I can still see the heap size gradually increased around 30MB after finishing a test file until it reached to the limit of memory capacity by V8 and shutdown the testing process.

Possible solution

Please if some of you resolved this leak by using nock.store, share what exactly you do, I do really appreciate it.

How to reproduce the issue

Runkit: Example link

Having problem producing a test case? Try and ask the community for help. If the test case cannot be reproduced, the Nock community might not be able to help you.

Does the bug have a test case?

Versions

Software Version(s)
Nock 13.0.4
Node 12.18.3
TypeScript
@mastermatt
Copy link
Member

What makes you think the leak if caused by Nock in your case? Is it possible the leak is coming from elsewhere?

@yuchenQ
Copy link
Author

yuchenQ commented Aug 24, 2020

What makes you think the leak if caused by Nock in your case? Is it possible the leak is coming from elsewhere?

You are definitely right, and I made an experiment which comments one dependency each time and then checks out whether the leak still exists or not, at last, we found the culprit is the usage of the nock.

And there are some issues already which pointed out the leak case. The intent of this issue is to get ideas if possible from people who suffered from this leak and fixed it by using nock.store or something else.

@paulmelnikow
Copy link
Member

Could you provide a minimal example repo which exhibits the leak?

@stale
Copy link

stale bot commented Dec 5, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We try to do our best, but nock is maintained by volunteers and there is only so much we can do at a time. Thank you for your contributions.

@stale stale bot added the stale label Dec 5, 2020
@stale stale bot closed this as completed Dec 13, 2020
@adamchenwei
Copy link

Why this is closed? I am also still experiencing this issue!

@mastermatt
Copy link
Member

@adamchenwei no one was able to provide a minimal example repo which exhibits the leak. We've yet to see actual confirmation that there is a memory leak. I'm not saying there isn't one, but several of us have tried to reproduce it without success. Any insight you can provide from your issues are welcome.

@RedTn
Copy link

RedTn commented Jul 19, 2022

@mastermatt

I have recreated the issue here: https://github.com/RedTn/nock-memory-leak

node: 16.10.0
nock: 13.2.8

Let me know if this works for you, I'm running into the exact same issue.
Else I can just make a new issue and reference this

@gr2m
Copy link
Member

gr2m commented Jul 19, 2022

Else I can just make a new issue and reference this

that would be preferable, thank you! Thank you for creating the repository to reproduce the issue, very helpful!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants