Memory Leak when using top-level await before defining computed translations

[azhirov]

Environment

• Operating System: Linux
• Node Version: v20.8.1
• Nuxt Version: 3.8.2
• CLI Version: 3.10.0
• Nitro Version: 2.8.1
• Package Manager: [email protected]
• Builder: -
• User Config: app, modules, devtools
• Runtime Modules: @pinia/[email protected], @nuxtjs/[email protected]
• Build Modules: -

Reproduction

I've created a minimal reproduction repository to illustrate the problem. To reproduce the issue:

1. Clone the repository: git clone [email protected]:azhirov/nuxt-i18n-pinia-memory-leak.git
2. Install dependencies: npm install
3. Build the project: npm run build
4. Run the server: node .output/server/index.mjs
5. Use a tool like ab, siege, or any other utility to send multiple requests. For example: siege -c10 -t30s http://127.0.0.1:3000 or ab -n 5000 -c 100 http://localhost:3000/
6. Check the memory consumption of the process (for example, using the top command).

Describe the bug

I've encountered a peculiar memory leak issue related to the simultaneous usage of the @nuxtjs/i18n and @pinia/nuxt modules in a Nuxt 3 project. The problem manifests when an asynchronous method from the Pinia store is called (using await) before a computed property that includes useNuxtApp().$i18n.t(). This results in a memory leak. Interestingly, moving the asynchronous method below the computed property prevents the leak. Additionally, if the $i18n.t() is not used in the computed property, the leak does not occur.

Code with memory leak:

import useFooStore from '~/store/foo';

const fooStore = useFooStore();
await fooStore.loadData()

const text = computed(() => {
  const i18n = useNuxtApp().$i18n;
  return i18n.t('seventeen');
})

After running the command node .output/server/index.mjs, the server consumes approximately 20 MB of RAM. However, after executing the command siege -c10 -t30s http://127.0.0.1:3000, the memory usage increases to 1.4 GB and remains at approximately this level even after stopping the load.

If you move the await call to the asynchronous method of the store below the computed property, the graph looks like this (the memory leak is significantly reduced, and memory consumption resets to almost the initial level).

I've noticed an interesting pattern: the memory leak seems to intensify with an increase in the number of translation files (in the lang directory).

Additional context

A similar issue was mentioned earlier in this comment: #2034 (comment). After updating to version 8.0.0-rc.11, the problem reproduces only when using Pinia. A simple asynchronous function defined within the same component does not trigger the memory leak.

Logs

No response

[BobbieGoede]

Thanks for reporting and providing a reproduction!

This sounds similar to #2034, I thought I fixed that 😥 hopefully I'll have time to debug this soon.

[agracia-foticos]

Same issue, i have stores before computed properties with t()

[BobbieGoede]

Hmm while working on fixing the other memory leak in this PR #2616 I did also test it on this reproduction https://github.com/danielroe/i18n-memory-leak and at that time it did seem to work.

@kazupon @danielroe
Maybe my testing method is flawed, if I use pnpm link [path to local i18n module] and build and test https://github.com/danielroe/i18n-memory-leak, the memory leak seems to be gone or minimal, but if I install the edge channel which should be essentially the same, the memory leak is present.

It's clear I need to read up on exactly what pnpm link does, but could this hint to the issue being related to a dependency (seeing as the lockfiles differ)? The memory leak that I did find and fix with #2616 did not behave differently when using pnpm link.

[azhirov]

@BobbieGoede I tried your method with my repo. I cloned @nuxtjs/i18n, installed dependencies (pnpm install), built it (pnpm run build), and then installed it locally in my reproduction repository.

However, the memory leak still persists, both in the main branch and on the v8.0.0-rc.11 tag.

[BobbieGoede]

@azhirov
Oh I failed to mention that I tested that as well and this wasn't the case with your reproduction, can you confirm that linking it locally in https://github.com/danielroe/i18n-memory-leak does seem to (mostly) resolve the memory leak? Trying to figure out what makes the difference but I maybe looking in the wrong direction 😅..

[azhirov]

@BobbieGoede
Sorry, I can't confirm that. I tested it with https://github.com/danielroe/i18n-memory-leak, and the memory leak persists even with the locally installed @nuxtjs/i18n module. This is true for both the main branch and the v8.0.0-rc.11 tag. Perhaps I am doing something wrong :(

[kazupon]

@BobbieGoede

Maybe my testing method is flawed, if I use pnpm link [path to local i18n module] and build and test https://github.com/danielroe/i18n-memory-leak, the memory leak seems to be gone or minimal, but if I install the edge channel which should be essentially the same, the memory leak is present.

I often build nuxt i18n as gzip with pnpm pack and add it to the target repro project with file protocol (file://) in deps.
This way has the advantage that the package manager is not affected by the link and implicitly by the package manager, and is completely isolate.

[BobbieGoede]

@kazupon
Ah I have used that too, I was hoping pnpm link would work the same without needing to zip and install 😥, my workflow for checking the memory leak is a bit slow.

@azhirov
No worries, I don't think the difference between the two reproductions matter much after all.

What's interesting is that this memory leak doesn't seem to be present if the translations are in i18n.config.ts instead of loading them in files. Still working on debugging this!

[BobbieGoede]

For some reason the memory leak is also gone when moving the computed translation inside a component. I forked your reproduction and added that workaround if you would like to try: https://github.com/BobbieGoede/nuxt-i18n-2629-memory-leak.

page (pages/no-leak-component.vue)

<script setup lang="ts">
import useFooStore from "~/store/foo";
import TranslationComponent from "~/components/TranslationComponent.vue";

const fooStore = useFooStore();
await fooStore.loadData();
</script>

<template>
	<div>
		<TranslationComponent />
	</div>
</template>

component (components/TranslationComponent.vue)

<script setup lang="ts">
const text = computed(() => {
	const i18n = useNuxtApp().$i18n;
	return i18n.t("seventeen");
});
</script>

<template>
	<div>
		{{ JSON.parse(JSON.stringify(text)) }}
	</div>
</template>

Perhaps this could work as a workaround, besides the known workaround of moving await after the computed variables. Will continue searching for the source of the issue but lower the priority label due to the issue's specificity.

[azhirov]

@BobbieGoede Certainly, this is an interesting approach, and it does address some issues.

However, I disagree that it can be a full-fledged workaround, as the result of computed might be used, for example, on the page - to be passed to useHead. In this case, the value may also depend on useAsyncData. As far as I understand, it's not possible to move this to a separate component, as the SSR result will differ from rendering on the client side.

I believe that the bug's priority remains "important", considering the widespread use of this module, including in production.

[BobbieGoede]

I'm not sure I fully understand your use case, as I understand it you can use derived values in computed regardless of whether these are fetched further down the script.

I have changed my fork to demonstrate this shouldn't cause SSR issues and changed the Pinia store to fetch from a server route, see https://github.com/BobbieGoede/nuxt-i18n-2629-memory-leak/blob/master/pages/index.vue for example.

I lowered the label priority as I think the usage is specific enough that I feel this shouldn't block v8 release, preventing users from migrating from v7 to v8. I'm not sure how widespread the usage is, if more projects are running into this I would like to know, I'll raise the priority again either way, as it does impact performance as the label describes.

[szwenni]

Hi
I'm also impacted by this problem.
The problem is we have a very very big project where this occured when we switched from loading from json files to a loader file and then having a async function which returns the tranlsations from a server response.

Two things I observed, messages loaded from a function are not cached at all, maybe this should be somehow configurable. If the lazy loaded messages are static why not cache them ?

Second thing, following the "Allocation instrumentation on timeline" with the chrome inspector I observed that the leak object is coming from here:

i18n/src/runtime/messages.ts

Line 59 in 4293f31

deepCopy(message, base)

I can till now not really tell why the objects are still referenced from somewhere, but each reload of the page a new object with all messages for a locale is spawned on the heap and keeps being referenced so GC is not triggered.

For us in production this leads to a crash of the application every x requests after the heap is filled.
As mentioned the application is quite big so I'm not really able to identify right now why this things are still referenced in some map somewhere and which WeakMap exactly is still referencing it. It looks like either the ssr payload or the state but I'm not able to verify it.

What I can surely tell is that we have no async pinia function which is executed on server side as all of our async pinia stuff is client side only (onMounted)

[s00d]

It seems I managed to localize and fix the issue.

https://github.com/s00d/i18n/tree/fix-leak

In the Nuxt documentation, they recommend using JSON instead of a class. I rewrote your code to import JSON, and the problem disappeared. Therefore, the memory leak is definitely related to generateTemplateNuxtI18nOptions.

Here is the documentation link.

https://nuxt.com/docs/api/kit/templates#examples

Here are my changes.

s00d@c6e4163
s00d@d05a972

Please note that this is just a code example, it's not very functional and triggers warnings due to JSON imports, but I believe it will help in identifying the issue.

[s00d]

It seems the problem is here.

i18n/src/gen.ts

Line 74 in b9c250e

importer.load = genDynamicImport(importSpecifier, !isServer ? { comment: `webpackChunkName: "${meta.key}"` } : {})

If we refactor it like this

importer.load = JSON.stringify(genDynamicImport(importSpecifier, !isServer ? { comment: `webpackChunkName: "${meta.key}"`, assert: { type: 'json' } } : { assert: { type: 'json' } }))

//...

const loadFunction = new Function('return ' + load)();
const getter = await loadFunction().then(r => r.default || r)

and also fix a few other places, for example, the path to the locale file, then the memory leak disappears.

In my example above, there are some changes that need to be made, but when switching to JSON, a lot of other problems arise. We need to find a different solution.

[szwenni]

After testing out a lot of stuff and trying to dig down the bug, I actually found out that for me it was related to the nuxt experimental feature called asyncContext.

When running with async context I can produce relative reliable a OOM with the leaking object (the loaded translations), when deactivated it just works fine.

For reference the description of the asyncContext feature
nuxt/nuxt#20918

[szwenni]

I made a reproduction here
https://github.com/szwenni/nuxt-i18n-memory-leak

I think one workaround, which is most probably not that clean, would be, when the messages are loaded for the first time for a language, store them in a global cache and then on the next loads just reference them from there instead of deepCloning them every time on every request. I'm not 100% sure what the intention behind the deepCloning is/was.

I would volunteer to do a pull request if nothing speaks against leaving out the deepCloning every time but just do it once on initial load for a locale. This would also save some GC time as it will result in a lot less allocations especially when you have big translation files.

Maybe it makes also sense to keep the deepCloning as default behavior but add an option which allows this caching to be enabled and circumvent the deepCloning of all messages every time.

[agracia-foticos]

Versión 8 final estable does memory leak also

[BobbieGoede]

@s00d
I'm unable to run this locally with the playground, I think the leak is not present because it may not be loading all translations. I think your changes would break dynamic translations as well but I haven't checked further yet.

@agracia-foticos
Unfortunately we haven't fixed this issue yet so it isn't included in the stable release, I'm still working hard on finding a fix.

@szwenni
Deep cloning happens because it's possible for locale files to fetch translations from a remote source or differ based on runtime config, I think it's possible to reduce the amount of deep cloning that happens but the order/priority of locale files would have to be taken into account as well as they can overwrite each other.

[szwenni]

For initial creating and loading the locale messages this seems okay but the deep cloning is happening on every route navigation right now (I checked it with the debugger).

I will try to implement my suggestion and you can check it if it makes sense or not.

In my repro I‘m using remote fetching with a loader. I did not check with local files which don‘t go through a loader and a remote api.

[szwenni]

okay
So switching off the asyncContext feature for me actually solved the "big" memory leak where the translations had been leaked.
But still some memory leak is happening somewhere (slower than before). Reloading the page a few times especially in dev mode is still filling up the heap a lot.

I need to investigate if I can find the object which is getting leaked but most probably some configuration object of the nuxt internals.

[s00d]

#2647

Basically, it seems that I found where the leak is. If you do as in my pull request, the leak disappears. It means that a reference is created in 'messages' and can't be destroyed. I spent a lot of time searching, but after the fix, everything started working fine. Unfortunately, due to such a solution, the framework began to work slower, but I think you will figure it out from here.

[s00d]

I've added new information here, and it's all much simpler than I thought. The issue lies with deepCopy, and my fix worked because the references in messages were removed.

[BobbieGoede]

@s00d
Can you check if #2654 works for you locally? It combines your findings about deepCopy with some optimizations.

Also, do you also still experience a small memory leak with the fixes so far? I suspect the messages leaking is a symptom of the context or i18n options leaking somewhere later in the code, but since the messages take up the largest amount of memory/space of the options it ends up being the most impactful.

[s00d]

@s00d Can you check if #2654 works for you locally? It combines your findings about deepCopy with some optimizations.

Also, do you also still experience a small memory leak with the fixes so far? I suspect the messages leaking is a symptom of the context or i18n options leaking somewhere later in the code, but since the messages take up the largest amount of memory/space of the options it ends up being the most impactful.

Sorry, I didn't check which pull request you were writing about, I'll check now.

Locale retrieval is not working.|

Regarding structuredClone, I tested it a couple of weeks ago; it operates slower than JSON.parse(JSON.stringify()).

[BobbieGoede]

Can you check if you're still experiencing the leak using the latest edge release? (npm i -D @nuxtjs/i18n@npm:@nuxtjs/i18n-edge@latest)

I made some changes in vue-i18n (intlify/vue-i18n#1677) that should reduce memory usage and it seems the messages are not leaking (as much) anymore. I still don't think this removes the leak fully, a very small leak is likely still present.

[wizzout]

Can you check if you're still experiencing the leak using the latest edge release?

I've checked on my own stand with same problem - no more memory leaks! Total heap size increases when there ara many active request, but then return to normal value fast. Really waiting release of this fix! Thank You!

[BobbieGoede]

@wizzout
Thanks for checking the fix! Hopefully we can release this fix soon, awaiting more confirmation, it seems like the leak may still be present for some setups (#2612 (comment))

@azhirov @s00d
Can you confirm if the leak has been resolved in your project using the latest edge release? You may need to remove node_modules and lockfiles before installing.

[s00d]

@azhirov @s00d
Can you confirm if the leak has been resolved in your project using the latest edge release? You may need to remove node_modules and lockfiles before installing.

Checked on one of the test repositories, everything is fine now. Unfortunately, it will take significantly more time for the others. For now, we have worked around the issue with temporary solutions. I will try to do more testing.

[azhirov]

I have checked several versions of the module for memory leaks. The repository https://github.com/azhirov/nuxt-i18n-pinia-memory-leak was used for testing. Before installing a new version each time, I deleted package-lock.json and the node_modules directory. Then I built the project and ran it: nuxi build && node .output/server/index.mjs

For load testing, the command siege -c10 -t30s http://127.0.0.1:3000 was used.

Here are the results:

8.0.0-rc.5 ✅

No leaks, no errors in console output ("vue-i18n": "9.5.0")

RAM usage graph (click to view)

8.0.0-rc.6 ❌

There is a leak, and there is an error [nuxt] [request error] [unhandled] [500] Maximum call stack size exceeded

RAM usage graph (click to view)

8.0.0-rc.7 ❌

There is a leak, and there is an error [nuxt] [request error] [unhandled] [500] Maximum call stack size exceeded

RAM usage graph (click to view)

8.0.0-rc.8 ❌

There is a leak, and there is an error [nuxt] [request error] [unhandled] [500] Maximum call stack size exceeded

RAM usage graph (click to view)

8.0.0-rc.9 ❌

There is a leak, and there is an error [nuxt] [request error] [unhandled] [500] Maximum call stack size exceeded

RAM usage graph (click to view)

8.0.0-rc.10 ❗️

No leaks, but there is an error [nuxt] [request error] [unhandled] [500] Maximum call stack size exceeded

RAM usage graph (click to view)

8.0.0-rc.11 ✅

No leaks. No errors. I was surprised here because this version had the issue. I examined the package-lock.json file and found that a new version of the vue-i18n package (9.9.1) is now installed.

RAM usage graph (click to view)

8.0.0-rc.11 and [email protected] ❌

There is a leak. To check, I deliberately installed an old version of vue-i18n using the command npm i --save [email protected]. No errors in console output.

RAM usage graph (click to view)

[email protected] ✅

No leaks. Probably because the minimum version of the package is specified in the dependencies: "vue-i18n": "^9.9.0". No errors in console output.

RAM usage graph (click to view)

---

I might be mistaken, but it seems that the leak was in the vue-i18n package, and it is fixed in version 9.9.0. Therefore, in the production environment, it is sufficient to specify in package.json:

"@nuxtjs/i18n": "8.0.0",
"vue-i18n": "^9.9.0"

No need to install @nuxtjs/i18n-edge@latest.

[BobbieGoede]

@azhirov
Thank you for your thorough testing, this is great!

You're right, most if not all of the memory leak was fixed in [email protected], a fresh install of @nuxtjs/i18n@^8.0.0 should use this version as well (as you noticed with rc.11). There have been a few changes since release so it's good to see that the edge release is still doing well memory wise in your setup.

Will soon publish a patch release with the recommendation to refresh lockfiles when updating to ensure the latest vue-i18n is installed along with it. After which I'll close this issue, thanks again for providing your minimal reproduction and this detailed report!

[szwenni]

Hello all
for me the problem still exists. I can see in the heap dump of the nuxt process a high amount of copies of the messages for each language, all referenced in different vueI18nOptions objects.

For context we have around 40 different languages, and after some time (around 20 mins) it has filled up all the available heap, crashes and restarts. Only then the heap is again freed but till then it always fills up everything.

A heap dump created after 10 minutes in our productive environment shows around 50 copies of the 'de' messages object (which is the default language) in 50 different vueI18nOptions objects. And this piles up.

So somehow this problem is still not fixed. From configuration point of view I changed nothing than the things already described above.

I'm not sure how to make a reproduction if this entirely and if I should create a new issue or this one can be reopened.

[BobbieGoede]

@szwenni
Since we're unable to trigger a memory leak with the reproductions in the closed issues you're likely experiencing a different issue/leak. Please open a new issue with a reproduction so we can debug it.

[szwenni]

@BobbieGoede
I just tested it with my repdroduction and it stills triggers it.
https://github.com/szwenni/nuxt-i18n-memory-leak
If you run this locally, take a heap snap-shot at the beginning, cycle through some languages, and take a snapshot again.
In the array section of the heap snapshot you will see a lot of objects with the same size at end and many objects are references to a messages object from a vueI18nOptions object. And like said these are often from the same language.

[liorchamla]

I might be mistaken, but it seems that the leak was in the vue-i18n package, and it is fixed in version 9.9.0. Therefore, in the production environment, it is sufficient to specify in package.json:

"@nuxtjs/i18n": "8.0.0",
"vue-i18n": "^9.9.0"

No need to install @nuxtjs/i18n-edge@latest.

Hello to all, we had a problem with a newly push to production Nuxt 3 app. This modification to packages.json made the trick in local. We will deploy a new release of our app soon in prod container.

For context :

• Node 18.16.0 with old dependencies + Artillery test scenarios : the app goes up to 2GB RAM and does not come back even after the tests end
• Node 18.16.0 with new dependencies + Artillery test scenarios : the app reaches 800MB MAX and the RAM itself is sooo much variable, even when the tests are running, we see the garbage collector at work.

So, to conclude, @azhirov : thank you so much mate.

[vhovorun]

@szwenni Hey have u found the solution to your leak? Seems like I have the same problem

[BobbieGoede]

@vhovorun
Can you open a new issue with a minimal reproduction? 🙏

[szwenni]

So actually there are two sides I think

• I have the feeling there is still a memory leak somewhere but it is quite hard to identify which object leaks
• second thing is that the createMatcher / match route method is quite slow when having a lot of routes

This both things together and additionally node being under pressure (a lot of requests, e.g. google is traversing your site) leads to node no having the time to gc fast enough also the big objects and then finally lead to a oom

I for myself fixed this by using someones pull request where he adopted the routematcher to not use only regex but also a tree. This actually speed up the whole application by 1000% and till now I did not have any issues.
vuejs/router#2148

[BobbieGoede]

@szwenni
Yep the amount of routes has a significant impact on performance since Vue Router v4 (which Nuxt 2 does not use), we're tracking that here vuejs/router#2132, this is more noticeable for i18n projects due to the generated routes. Have you also checked the performance using Vue Router 4.3.3 or higher? This includes vuejs/router#2137 and should be much more performant.

Of course if vuejs/router#2148 works well that's great, there's also room for the i18n module to improve routing performance (and build size) by changing the matching approach such as #2937. It's all an ongoing effort 😅

[s00d]

@szwenni Yep the amount of routes has a significant impact on performance since Vue Router v4 (which Nuxt 2 does not use), we're tracking that here vuejs/router#2132, this is more noticeable for i18n projects due to the generated routes. Have you also checked the performance using Vue Router 4.3.3 or higher? This includes vuejs/router#2137 and should be much more performant.

Of course if vuejs/router#2148 works well that's great, there's also room for the i18n module to improve routing performance (and build size) by changing the matching approach such as #2937. It's all an ongoing effort 😅

Hello. After careful consideration, I've decided to preserve all my work on this project. I've invested a significant amount of time and effort into it, and I'm quite proud of the results.

https://github.com/s00d/nuxt-i18n-micro

Perhaps others have encountered similar challenges. I've detailed the issues and solutions in the README. Currently, my module offers a 2-3x performance improvement in most cases, and up to a 10x speedup in some scenarios. It's also smaller, simpler, and easier to understand.

[BobbieGoede]

@s00d
The performance comparison looks impressive! Are you planning on supporting a specific set of features or working towards a similar feature set as this module?

Having more modules explore i18n should make for a healthier ecosystem 💪

[s00d]

The performance comparison looks impressive! Are you planning on supporting a specific set of features or working towards a similar feature set as this module?

Having more modules explore i18n should make for a healthier ecosystem 💪

It's difficult to say what the future holds right now. My current focus is on understanding how Vite and Nuxt work together, and I'm not just optimizing the build process, but also enhancing the module's runtime performance. I chose not to use Vue i18n due to the numerous issues I've personally encountered, which has brought both advantages and challenges. At the moment, my priority is catching bugs and getting the module ready for production. After that, we'll see what direction things take.

I'm also exploring how to properly implement type definitions for the Nuxt plugin. So far, I haven't managed to create a fully functional solution—I've only been able to achieve some level of typing in the IDE through composables. Unfortunately, neither the documentation nor GitHub searches have provided clear answers. There are still a lot of hurdles to overcome before I can start thinking about expanding the module's features.

[vhovorun]

@BobbieGoede Hey, I found the problem and it wasn't obvious at all 😅 but maybe it will save for someone a lot of time, in my case the fix was switching from 22.5.1 node version to 22.0.0 after that memory goes high but it resets back to normal