memory leak in got@11
Kikobeats opened this issue · 14 comments
Describe the bug
got@11 is still very used, and it depends on cacheable-request@7.0.2. There is a bug resolved recently that is still present in that cacheable-request version:
https://github.com/jaredwray/cacheable-request/releases/tag/v10.2.6
How To Reproduce (best to provide workable code or tests!)
The following commit should be ported in order to address the issue of the v7 tag version:
main...Kikobeats:cacheable-request:buggy
Also, the changes include the use of an optional operator for accessing cache event emitter methods; In that way, it's possible to avoid the issue if the cache provided that doesn't extend from EventEmitter (so there is no event to attach neither remove)
I can't promote a PR here since the only branch is main. Could you please integrate this changes and release cacheable-request@7.0.3? 🙂
@Kikobeats - thanks for the note and we do have a commonjs branch but it is later in the release.
Do you want to create a new one and I can look at doing a release as 7.0.3?
Let me know if you want to chat about how to do this best.
done!
I am wondering if we need to pull the code from v7 and create that as a branch as the current one is too new still and after testing there seems to be a ton of changes.
What if I created a branch that is just based on https://github.com/jaredwray/cacheable-request/releases/tag/v7.0.2 then you do a pull request against that with these changes?
The other option is that we take the merge in on commonjs branch. Then we do a test to see if it breaks GOT if we release this updated code base as v7.0.3.
Thoughts?
@Kikobeats - I went ahead and did a new branch called v7. I also added in the code changes that you outlined.
Could you validate this before I do the fix and release it as v7.0.3?
The reason I would like to test this is that there are significant code changes between this code and v7.0.2 and i want to make sure we are good with this release.
Hello,
is this the code change? c09f1cd
The code looks good to me. It could better if a test unit is added.
Thanks. Do you want to add a unit test to the v7 branch to validate? Also, how can we test that this version of cacheable-request works well with got@11? Is there a place to validate it well or a scenario where you are seeing the memory leak?
@Kikobeats - have you been able to validate this code change?
Sorry for the delay. The scenario is api.microlink.io, the endpoint is handling +50M requests per month, so it's very sensitive to little bugs like this.
Unfortunately, I don't have the time for writing the test – If you ship v7.0.3 I can test it on production servers and tell you 🙂
https://www.npmjs.com/package/cacheable-request/v/7.0.3 with tag beta
@jaredwray this version 7.0.3 broked new deploys in node version < 14. Please, check this issue: #246
Thanks. the new release v7.0.4 should have resolved as it is based on 7.0.2.
@Kikobeats - I rolled this back and did some changes on it for v7.0.5-beta.0 as it caused multiple issues. You can test this out by referencing the following github path.
https://github.com/jaredwray/cacheable-request/tree/v7
To do this in your npm package do the following:
// in your package.json
"dependencies": {
"cacheable-request": "jaredwray/cacheable-request#v7",
}
closing on no response