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: npm@10.1.0
• Builder: -
• User Config: app, modules, devtools
• Runtime Modules: @pinia/nuxt@0.5.1, @nuxtjs/i18n@8.0.0-rc.11
• Build Modules: -

Reproduction

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

1. Clone the repository: git clone git@github.com: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.