For the past week and a half, my test suite has been dying of something I cannot diagnose. I am writing this mid-shitstorm, because the shape of it is one every engineer eventually stumbles into and the honest version is more useful than the tidy one.

Giant Context ships everything through its test suite. Several hundred test files gate every push. The pipeline will not deploy a service until the suite is green. So when the suite starts dying randomly, the whole company is standing behind it in line.

The suite runs, climbs to around the twenty-minute mark, and then a test worker prints this and drops dead:

The runtime killed the process for asking more memory than it is allowed. The suite restarts, climbs another twenty minutes, and sometimes finishes and sometimes dies again. A deploy needs the suite green on the feature branch, then on dev, then on prod, so that one unlucky day prices a single change at forty minutes an environment. Two hours of watching a progress bar to ship a fix I wrote in ten minutes.

The irregularity was the maddening part. It failed on GitHub's runners often and locally almost never. Locally I am on a machine with memory to spare, which made the out-of-memory theory feel wrong even while the error message insisted on it. But GitHub was where it hurt. Its evidence is what I chased.

The commit log of that week records the swings.

Vitest, my test runner, can spread test files across separate processes, called forks, or across threads inside fewer processes. Which one you choose changes how memory adds up. That setting moved twice in four days. In between, the memory limit went up, which treats the symptom and names no cause, and the entire UI package got mocked with a JavaScript Proxy, a single object that pretends to be every component at once. The Proxy lived about six hours.

Every one of these changes looked reasonable. None of them moved the failure rate much. That is what a misdiagnosis feels like from the inside. The moves are locally sound. The target is wrong. The log fills with reverted convictions.

The change that survived is the one whose file explains itself. My test mock for the UI package now opens with this:

A barrel file is a package's front index, one file that re-exports everything the package offers so consumers can import from one place. I enforce barrels everywhere in this codebase as a matter of doctrine. This is what the doctrine costs. When a test file imports one button from the UI package's barrel, the barrel loads everything it exports. All of the component library, the data grids, the chart library, fifty-some custom components, into that test worker's memory. Across every test file that touches any component, times every worker, the suite was carrying the whole UI universe hundreds of times over.

The mock kills the multiplication. Tests that import the UI package get this file instead, which hands back real components fetched from their individual paths, one by one, and cheap stubs for the heavy machinery. The imports stay honest and the memory stays flat. No Proxy cleverness is required. In test workers, memory dies by import graph. The barrel is the fattest node in that graph.

The status from here is uncomfortable. The suite is far more stable than it was two weeks ago. Caching keeps repeat runs cheap and the barrel mock keeps workers thin. The pool settings have settled where they belong. Close to bulletproof, most days.

And I still do not know what the problem is. Nothing I did found it. Everything I did made the suite strong enough to live with it, which is not the same thing. Pretending otherwise is how this kind of bug comes back. Something in this codebase still leaks or loops under memory pressure, showing itself only on small machines under full load. It is still unfound.

Three lessons hold up from here. When out-of-memory strikes irregularly, check what your imports are loading before you raise any memory limit. Mine was pulling the entire UI library into every test worker through one innocent-looking import, which no limit was going to survive. Write down why every surviving config setting exists, because in six months nobody remembers why the pool is set the way it is and whoever cleans it up brings the problem back. And when the failures stop before the diagnosis arrives, say so out loud, in the log and to yourself. A bug that went quiet and a bug that died are different things.