The Arrow Function That Made a Memory Leak Untraceable for Three Days

Arrow functions solved the chaos of lexical this. A decade of mindless overuse has created a new problem: anonymous stack traces, broken reference stability, and garbage collection bottlenecks in the places your application can least afford them.

The memory leak took three days to find. The application was a real-time data dashboard — the kind that streams live market data into a grid of hundreds of rows, updating on every tick. Performance had degraded slowly over the course of a session until, after about forty minutes, the browser tab became unresponsive.

The flame chart showed GC pressure. The heap snapshot showed accumulation. The stack traces showed <Anonymous>. Every callback in the codebase was an inline arrow function, so when the profiler tried to tell us which operation was leaking, it had nothing to say. Three engineers spent three days narrowing down the source by process of elimination, commenting out callback registrations one by one until the leak stopped.

The callback that caused it was eleven characters long. The fix was to add a name to it and extract it from the inline registration. The three days of investigation were caused entirely by the fact that it had no identifier the profiler could report.

The mechanism: what inline arrow functions actually do in memory

Every time a JavaScript engine encounters a function literal that includes an arrow function, it allocates a new function object in memory. This is not a property of arrow functions specifically; it is a property of all inline function definitions. The distinction that matters is whether that allocation is necessary or incidental.

For a short-lived operation, a .map() callback that runs once, or a click handler that fires occasionally, the allocation cost is negligible. The GC collects the function object shortly after use, and the heap stays clean.

The problem is hot paths: operations that execute at high frequency, repeatedly, in tight loops, or on every frame.

// New function object allocated on every tick — every 16ms at 60fps
socket.on('tick', (data) => {
  updateGrid(data);
});

// Not a problem at first — but this registration happens inside a component
// that mounts and unmounts during navigation.
// Each mount creates a new anonymous callback.
// Each unmount... can't remove it. You don't have the reference.

The second problem is reference equality. JavaScript uses referential equality for function comparison; two function objects are equal only if they are literally the same object in memory, not if they have identical code. This has a specific consequence in component architectures: an inline arrow function passed as a prop creates a new reference on every render, which means downstream components that use memoization to avoid unnecessary re-renders will see a "changed" prop every single time, regardless of whether the actual behavior changed.

// New function reference created on every render of ParentComponent
function ParentComponent() {
  return <DataGrid onRowSelect={(row) => handleSelect(row)} />;
}

// DataGrid's memo is useless — onRowSelect is always a different object
const DataGrid = React.memo(({ onRowSelect }) => {
  return <Grid onSelect={onRowSelect} />;
});

The combination of these two problems, GC pressure from repeated allocation and broken memoization from unstable references, is what makes mindless arrow function usage an architectural issue rather than a style preference.

The real-world cost: three failure modes in production

Unidentifiable stack traces and high MTTR

The most immediate operational cost is in incident response. When a production error occurs in an anonymous callback, your error tracker, Sentry, Datadog, or whatever you use, captures a stack trace. If every frame in that trace is <Anonymous>, the trace tells you that something failed somewhere in a callback, during some operation, at some point.

This is not a theoretical concern. In the three-day debugging session described above, the issue was not the leak itself; the leak pattern was well understood once we found it. The issue was that without names in the stack trace, every diagnostic tool we had was blind. We were debugging a production system in the dark.

Named callbacks fix this entirely at zero runtime cost:

// Before — anonymous, invisible in traces
socket.on('tick', (data) => updateGrid(data));

// After — named, identifiable in every profiler, error tracker, and flame chart
const handleTickUpdate = (data) => updateGrid(data);
socket.on('tick', handleTickUpdate);

The function object is the same. The allocation cost is the same. The only difference is that handleTickUpdate now appears in every tool that tries to tell you what went wrong.

Memory leaks from unremovable event listeners

removeEventListener requires a reference to the exact function object that was passed to addEventListener. An anonymous inline arrow function, by definition, has no stored reference, which means it can never be removed.

// This listener is permanent — there is no way to remove it
window.addEventListener('resize', () => {
  recalculateLayout();
});

// This listener can be removed when the component unmounts
const handleResize = () => recalculateLayout();
window.addEventListener('resize', handleResize);

// In cleanup:
window.removeEventListener('resize', handleResize);

In a long-lived SPA where users navigate for hours without a full page reload, permanently registered event listeners accumulate. Each one holds a closure reference to whatever was in scope when it was created. In a data-heavy application, those closures can hold references to large datasets, and since the listener can never be removed, those datasets can never be garbage collected.

This is exactly the failure mode that produced the three-day debugging session. The leak was not complex. The anonymity made it untraceable.

Reference instability and broken memoization

React's memo, useMemo, and useCallback all rely on stable references to work correctly. When an inline arrow function is passed as a prop or dependency, every render creates a new reference, which defeats memoization at that boundary.

// Problematic — new reference every render
function FilterPanel({ data }) {
  return (
    <ExpensiveList
      data={data}
      filterFn={(item) => item.active && item.value > 0}
    />
  );
}

// Stable — same reference across renders unless dependencies change
function FilterPanel({ data }) {
  const filterFn = useCallback(
    (item) => item.active && item.value > 0,
    [] // no dependencies — truly stable
  );

  return <ExpensiveList data={data} filterFn={filterFn} />;
}

In 2026, automated compiler optimizations handle a significant portion of basic memoization. React's compiler, for instance, can detect and stabilize some inline callbacks automatically. But these optimizations have limits: they cannot stabilize callbacks that close over props or state without the compiler being able to prove the dependencies are stable. And they cannot fix the fundamental problem of anonymous callbacks in global event listeners or stream handlers, which live outside the component model entirely.

The discipline of stable references remains necessary. The compiler assists it; it does not replace it.

The fix: four enforced patterns for callback discipline

Extract and name callbacks in hot paths

Any callback that runs at high-frequency socket handlers, scroll listeners, animation frame callbacks, or stream processors should be extracted to a named, stable reference before it is registered.

// High-frequency stream handler — extracted and named
const processMarketTick = (tick) => {
  const normalised = normaliseTick(tick);
  dispatch({ type: 'TICK', payload: normalised });
};

// Registered once, removable, identifiable in stack traces
socket.on('market:tick', processMarketTick);

// Cleanup
return () => socket.off('market:tick', processMarketTick);

The extraction pattern costs nothing at runtime. It buys you identifiable stack traces, removable listeners, and a stable reference that memoization can rely on.

Use useCallback for prop callbacks in memoized components

Any callback passed as a prop to a React.memo component or used as a dependency in another hook should be stabilized with useCallback.

function DataTable({ userId }) {
  const handleRowSelect = useCallback((row) => {
    analytics.track('row_selected', { userId, rowId: row.id });
  }, [userId]); // re-created only when userId changes

  return <MemoizedGrid onSelect={handleRowSelect} />;
}

useCallback is not a universal performance win; it has its own overhead and should only be applied where reference stability actually matters. The signal for when it matters: the callback is passed to a React.memo component or used as a dependency in a useEffect or useMemo that has a meaningful cost to re-run.

Enforce a nesting depth limit on arrow function chains

Deeply nested arrow functions—const process = a => b => c => d => {}—are a specific antipattern that compounds the problems above: Each level creates a new closure, each closure captures the outer scope, and the resulting stack trace (if named at all) shows only the outermost identifier, making inner failures invisible.

Add this to your ESLint configuration:

{
  "rules": {
    "max-nested-callbacks": ["error", { "max": 2 }],
    "prefer-named-capture-group": "warn"
  }
}

The practical rule: if an arrow function returns another arrow function, the inner one should be extracted to a named utility. Currying beyond one level belongs in a clearly named composition utility, not inline.

Audit event listener registrations

Add this to your code review checklist as a blocking item: every addEventListener call must have a corresponding removeEventListener call in a cleanup function, and both must reference the same named variable.

# Find addEventListener calls — check each has a named reference and cleanup
grep -rn "addEventListener" src/ | grep -v "removeEventListener"

Any result from that search is a candidate for a permanent leak. The fix is always the same: extract the callback to a named variable, store the reference, and clean up in componentWillUnmount, the useEffect return function, or the service's destroy method.

Key takeaway

Arrow functions are an excellent tool for concise, short-lived, clearly scoped operations. They were designed for inline callbacks, array method chains, and closures where preserving lexical this matters. They were not designed to replace disciplined naming and reference management across an entire codebase.

The senior engineering instinct is not to avoid arrow functions; it is to recognize which callbacks have architectural weight and which do not. A .filter() lambda over a small array has no architectural weight. A socket handler that runs hundreds of times per second, holds a closure over a large dataset, and must be cleanly removable has significant architectural weight, and it deserves a name, a stable reference, and an explicit cleanup path.

Your production monitoring tools can only help you when your code gives them something to report. A stack trace full of <Anonymous> is not a tool failure; it is a design decision made months earlier at the keyboard.

What to audit this week

# Find anonymous arrow functions registered as event listeners
grep -rn "addEventListener('" src/ | grep "=>"

# Find socket or stream handlers registered inline
grep -rn "\.on('" src/ | grep "=>"

# Find deeply nested arrow function chains
grep -rn "=> .* =>" src/ --include="*.ts" --include="*.tsx"

Any result from the first two searches is a leak risk and a stack trace blind spot. Any result from the third is a readability and debuggability problem waiting to become a production incident.