[Bug]: OOM While trying to migrate from Jest

[n0th1ng-else]

Version

System:
    OS: macOS 26.2
    CPU: (12) arm64 Apple M2 Pro
    Memory: 8.41 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Browsers:
    Chrome: 145.0.7632.119
    Firefox: 148.0
    Safari: 26.2
  npmPackages:
    @rstest/core: 0.8.5 => 0.8.5

Details

Hello folks. I am doing some POC work in our huge monorepo.

wanted to migrate around 30% of our test codebase (1790 test files, 15320 tests) in one of the workspaces to see how challenging it is, and also compare it to vitest.

This OOM blocks me from making further progress. Maybe it is something fixable? I understand I have no good reproduction, and this is probably due to the repo size. But I want to confirm this with you as well.

% npx rstest
  Rstest v0.8.5


 Test Files 0 total
   Duration 34.1s

<--- Last few GCs --->

[28849:0x86280c000]    37807 ms: Mark-Compact 1304.3 (1425.0) -> 1281.0 (1461.0) MB, pooled: 42 MB, 30.79 / 0.00 ms  (+ 0.2 ms in 11 steps since start of marking, biggest step 0.2 ms, walltime since start of marking 179 ms) (average mu = 0.933, current mu
FATAL ERROR: invalid table size Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0x1021542e4 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
 2: 0x102354868 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
 3: 0x1025b4498 v8::internal::Heap::stack() [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
 4: 0x1028da71c v8::internal::DirectHandle<v8::internal::NumberDictionary> v8::internal::HashTable<v8::internal::NumberDictionary, v8::internal::NumberDictionaryShape>::EnsureCapacity<v8::internal::LocalIsolate, v8::internal::DirectHandle>(v8::internal::LocalIsolate*, v8::internal::DirectHandle<v8::internal::NumberDictionary>, int, v8::internal::AllocationType) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
 5: 0x1028db3e0 v8::internal::DirectHandle<v8::internal::NumberDictionary> v8::internal::Dictionary<v8::internal::NumberDictionary, v8::internal::NumberDictionaryShape>::Add<v8::internal::Isolate, v8::internal::DirectHandle, (v8::internal::AllocationType)0>(v8::internal::Isolate*, v8::internal::DirectHandle<v8::internal::NumberDictionary>, unsigned int, v8::internal::DirectHandle<v8::internal::Object>, v8::internal::PropertyDetails, v8::internal::InternalIndex*) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
 6: 0x1027885a4 v8::internal::(anonymous namespace)::DictionaryElementsAccessor::AddImpl(v8::internal::DirectHandle<v8::internal::JSObject>, unsigned int, v8::internal::DirectHandle<v8::internal::Object>, v8::internal::PropertyAttributes, unsigned int) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
 7: 0x102864e38 v8::internal::JSObject::AddDataElement(v8::internal::DirectHandle<v8::internal::JSObject>, unsigned int, v8::internal::DirectHandle<v8::internal::Object>, v8::internal::PropertyAttributes) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
 8: 0x1028eb440 v8::internal::Object::AddDataProperty(v8::internal::LookupIterator*, v8::internal::DirectHandle<v8::internal::Object>, v8::internal::PropertyAttributes, v8::Maybe<v8::internal::ShouldThrow>, v8::internal::StoreOrigin, v8::internal::EnforceDefineSemantics) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
 9: 0x102a1d5a0 v8::internal::Runtime::SetObjectProperty(v8::internal::Isolate*, v8::internal::DirectHandle<v8::internal::Union<v8::internal::Smi, v8::internal::HeapNumber, v8::internal::BigInt, v8::internal::String, v8::internal::Symbol, v8::internal::Boolean, v8::internal::Null, v8::internal::Undefined, v8::internal::JSReceiver>>, v8::internal::DirectHandle<v8::internal::Object>, v8::internal::DirectHandle<v8::internal::Object>, v8::internal::MaybeDirectHandle<v8::internal::Union<v8::internal::Smi, v8::internal::HeapNumber, v8::internal::BigInt, v8::internal::String, v8::internal::Symbol, v8::internal::Boolean, v8::internal::Null, v8::internal::Undefined, v8::internal::JSReceiver>>, v8::internal::StoreOrigin, v8::Maybe<v8::internal::ShouldThrow>) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
10: 0x10266c39c v8::internal::Runtime_KeyedStoreIC_Slow(int, unsigned long*, v8::internal::Isolate*) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
11: 0x10306df74 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
12: 0x1260c7d5c
13: 0x102fce8cc Builtins_JSEntryTrampoline [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
14: 0x102fce570 Builtins_JSEntry [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
15: 0x1024f86e4 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
16: 0x1024f8048 v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::DirectHandle<v8::internal::Object>, v8::internal::DirectHandle<v8::internal::Object>, v8::base::Vector<v8::internal::DirectHandle<v8::internal::Object> const>) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
17: 0x1026dcc9c v8::internal::JsonStringifier::ApplyToJsonFunction(v8::internal::Handle<v8::internal::Union<v8::internal::Smi, v8::internal::HeapNumber, v8::internal::BigInt, v8::internal::String, v8::internal::Symbol, v8::internal::Boolean, v8::internal::Null, v8::internal::Undefined, v8::internal::JSReceiver>>, v8::internal::DirectHandle<v8::internal::Object>) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
18: 0x1026e292c v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_<false>(v8::internal::Handle<v8::internal::Union<v8::internal::Smi, v8::internal::HeapNumber, v8::internal::BigInt, v8::internal::String, v8::internal::Symbol, v8::internal::Boolean, v8::internal::Null, v8::internal::Undefined, v8::internal::JSReceiver>>, bool, v8::internal::Handle<v8::internal::Object>) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
19: 0x1026dc164 v8::internal::JsonStringifier::Stringify(v8::internal::Handle<v8::internal::Union<v8::internal::Smi, v8::internal::HeapNumber, v8::internal::BigInt, v8::internal::String, v8::internal::Symbol, v8::internal::Boolean, v8::internal::Null, v8::internal::Undefined, v8::internal::JSReceiver>>, v8::internal::Handle<v8::internal::Union<v8::internal::Smi, v8::internal::HeapNumber, v8::internal::BigInt, v8::internal::String, v8::internal::Symbol, v8::internal::Boolean, v8::internal::Null, v8::internal::Undefined, v8::internal::JSReceiver>>, v8::internal::Handle<v8::internal::Object>) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
20: 0x1026e2234 v8::internal::JsonStringify(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Union<v8::internal::Smi, v8::internal::HeapNumber, v8::internal::BigInt, v8::internal::String, v8::internal::Symbol, v8::internal::Boolean, v8::internal::Null, v8::internal::Undefined, v8::internal::JSReceiver>>, v8::internal::Handle<v8::internal::Union<v8::internal::Smi, v8::internal::HeapNumber, v8::internal::BigInt, v8::internal::String, v8::internal::Symbol, v8::internal::Boolean, v8::internal::Null, v8::internal::Undefined, v8::internal::JSReceiver>>, v8::internal::Handle<v8::internal::Object>) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
21: 0x1023d167c v8::internal::Builtin_JsonStringify(int, unsigned long*, v8::internal::Isolate*) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
22: 0x10306de94 Builtins_CEntry_Return1_ArgvOnStack_BuiltinExit [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
23: 0x125f8f580
24: 0x125f9063c
25: 0x102fd0bec Builtins_InterpreterEntryTrampoline [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
26: 0x125f910cc
27: 0x102fd0bec Builtins_InterpreterEntryTrampoline [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
28: 0x125f4efe4
29: 0x102fd0bec Builtins_InterpreterEntryTrampoline [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
30: 0x102fd0bec Builtins_InterpreterEntryTrampoline [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
31: 0x10300f648 Builtins_AsyncFunctionAwaitResolveClosure [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
32: 0x1030e45f8 Builtins_PromiseFulfillReactionJob [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
33: 0x102ffea50 Builtins_RunMicrotasks [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
34: 0x102fce7b0 Builtins_JSRunMicrotasksEntry [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
35: 0x1024f869c v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
36: 0x1024f8f10 v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
37: 0x1024f904c v8::internal::Execution::TryRunMicrotasks(v8::internal::Isolate*, v8::internal::MicrotaskQueue*) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
38: 0x102527ef8 v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate*) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
39: 0x102528858 v8::internal::MicrotaskQueue::PerformCheckpoint(v8::Isolate*) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
40: 0x102fd294c Builtins_CallApiCallbackOptimizedNoProfiling [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
41: 0x12653dd14
42: 0x102fce8cc Builtins_JSEntryTrampoline [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
43: 0x102fce570 Builtins_JSEntry [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
44: 0x1024f86e4 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
45: 0x1024f8048 v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::DirectHandle<v8::internal::Object>, v8::internal::DirectHandle<v8::internal::Object>, v8::base::Vector<v8::internal::DirectHandle<v8::internal::Object> const>) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
46: 0x10236c7e0 v8::Function::Call(v8::Isolate*, v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
47: 0x102055108 node::InternalCallbackScope::Close() [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
48: 0x102055344 node::InternalMakeCallback(node::Environment*, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context, v8::Local<v8::Value>) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
49: 0x1020687c4 node::AsyncWrap::MakeCallback(v8::Local<v8::Function>, int, v8::Local<v8::Value>*) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
50: 0x102285590 node::StreamBase::CallJSOnreadMethod(long, v8::Local<v8::ArrayBuffer>, unsigned long, node::StreamBase::StreamBaseJSChecks) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
51: 0x102286d2c node::EmitToJSStreamListener::OnStreamRead(long, uv_buf_t const&) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
52: 0x10228b198 node::LibuvStreamWrap::OnUvRead(long, uv_buf_t const*) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
53: 0x10228b8e0 node::LibuvStreamWrap::ReadStart()::$_1::__invoke(uv_stream_s*, long, uv_buf_t const*) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
54: 0x102fb8dec uv__stream_io [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
55: 0x102fc1414 uv__io_poll [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
56: 0x102fad7c4 uv_run [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
57: 0x102055b7c node::SpinEventLoopInternal(node::Environment*) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
58: 0x1021a80c0 node::NodeMainInstance::Run() [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
59: 0x10210e344 node::Start(int, char**) [/Users/sen/.nvm/versions/node/v24.12.0/bin/node]
60: 0x1859c1d54 start [/usr/lib/dyld]
zsh: abort      npx rstest

Running Rspack works just fine (~11Gb Ram for the dev server). I assume it is something with the threads orchestration then.

Reproduce link

N/A

Reproduce Steps

Not sure what can cause this

[9aoy]

Thanks for reporting this! We understand it's difficult to provide a minimal reproduction for issues specific to large monorepos.

The stack trace shows the OOM occurs during JSON.stringify while serializing data. Since you're on rstest 0.8.5, could you try upgrading to v0.9.0 first? We've optimized the serialization strategy in that release which may resolve this issue. #792

If the issue persists after upgrading, to help us narrow down the root cause, could you provide some additional information?

• Config files: Could you share your rstest.config.ts configuration and the generated Rspack config by running in debug mode (DEBUG=rstest npx rstest)？
• Smaller subset: Does the OOM still occur with a smaller subset of test files (e.g., 100 files)? This helps determine if it's a scaling issue.

[n0th1ng-else]

Sorry the config is very messy since I am trying things out, but for the general idea:

const {defineConfig} = require( '@rstest/core')
const path = require( 'path' )
const {getTSLoader} = require( './common.rspack.js')

const rootDir = __dirname
const repoRoot = path.resolve(rootDir, '../..')

const swcConfig = require(path.resolve(repoRoot, 'config/swc/swcrc.json'))
const clientConfig = require(path.resolve(rootDir, 'configs/client.rspack.js'))
const commonConfig = clientConfig()


module.exports = defineConfig({
	globals: true,
	testEnvironment: {name: 'jsdom', options: {url: 'http://localhost'}},
	include: ['**/*.spec.{ts,tsx}'],
	setupFiles: ['./rstest.polyfills.ts', 'vitest-canvas-mock', './setupRstest.ts'],
	clearMocks: true,
	source: {
		decorators: {
			version: 'legacy',
		},
		define: {
			__DEV__: false,
			__PROD__: false,
			__TEST__: true,
			__DEV_SERVER_URL__: '""',
			'globalThis.__webpack_public_path__': '""',
		},
	},

	resolve: {
		extensions: commonConfig.resolve.extensions,
		alias: {
			...commonConfig.resolve.alias,
		},
	},
	onConsoleLog: () => false,
	tools: {
		swc: swcConfig,
		rspack: (config, {rspack}) => {
			config.optimization = {
				...config.optimization,
				/**
				 * Changing both `removeAvailableModules` AND `removeEmptyChunks` will cause memory leak
				 * https://github.com/web-infra-dev/rspack/issues/10320
				 */
				removeAvailableModules: true,
				removeEmptyChunks: true,penWidgetMenu.spec.ts
			}

			config.plugins.push(new rspack.NormalModuleReplacementPlugin(/\.(css|less|scss)/, 'identity-obj-proxy'))
			config.output.clean = true
			config.resolveLoader = commonConfig.resolveLoader

			const tsLoaders = [getTSLoader()]

			config.module.rules ??= []

			config.module.rules = [
				{
					oneOf: [
						{
							test: /\.tsx?$/,
							use: tsLoaders,
						},
						{
							resourceQuery: /svgr/,
							use: [
								{
									loader: '@svgr/webpack',
									options: {
										icon: true,
										ref: true,
									},
								},
							],
							type: 'javascript/auto',
						},
						{
							resourceQuery: /raw/,
							type: 'asset/source',
						},
						{
							test: /\.html$/,
							use: [
								{
									loader: 'html-loader',
								},
							],
							exclude: /packages\/static-assets\/html\/.*\.html$/,
						},
						{
							test: /\.(svg|jpeg|png|jpg|gif|mp4|webp|webm|avif|avifs|ico|wav|mp3|aac|ogg)$/,
							type: 'asset/resource',
						},
						{
							test: /\.(ttf|eot|woff|woff2|txt|bin)$/,
							type: 'asset/resource',
						},
						...config.module.rules,
					],
				},
			]

			return config
		},
	},
})

Try rstest 0.9

nice, thank you. I need to do more research but the first run went through (no OOM)

Try subset of test

This is what I tried, yes. tried 100 tests, it is failing. On ~60 test it worked. But I think it in more related to the specific test files, which have a huge import tree.

[n0th1ng-else]

@9aoy ok with v0.9 it goes much better, thanks for the headsup! 👍🏿

Now I have another problem that on CI it consumes all the memory and dies. Although locally it work fine. Do we have or plan something similar to workerIdleMemoryLimit maybe, to limit the ram consumptions by the workers? I see we still have CPU capacity on the runners, but RAM goes too high

[9aoy]

Now I have another problem that on CI it consumes all the memory and dies. Although locally it work fine. Do we have or plan something similar to workerIdleMemoryLimit maybe, to limit the ram consumptions by the workers? I see we still have CPU capacity on the runners, but RAM goes too high

There isn’t a feature similar to workerIdleMemoryLimit yet. We’ll look into how to support it.