The Async/Await Trap: Why Your Node.js Production System Is Probably Leaking

I once spent 48 hours on call, staring at Grafana dashboards showing a slow, steady climb in Node.js process memory. We were losing production requests, not all at once, but enough to matter. The culprit? A subtle misuse of async/await that was, over time, creating a memory leak that defied easy detection.

Why this matters in 2026. We've been sold async/await as the silver bullet for asynchronous JavaScript. It makes callback hell a distant memory and promises cleaner, more readable code. But the reality, especially in high-throughput production systems running Node.js (we're still on Node.js v18.18.0 in many critical services), is that it’s a sharp tool. Misuse it, and you’re not just writing slightly messy code, you're building a ticking time bomb that will eventually explode in your face during peak traffic. This isn't theoretical; it's the difference between a stable service and a PagerDuty nightmare.

The "Lost" Promises and the Growing Heap

The most insidious async/await trap is the "lost" promise. When you write code like this:

async function processData(itemId) {
  const data = await fetchData(itemId); // Assume fetchData returns a Promise
  // What if an error occurs after fetchData resolves but before await anotherAsyncOperation()?
  // And what if anotherAsyncOperation also returns a Promise?
  await anotherAsyncOperation(data);
  // If an error happens here, the promise returned by anotherAsyncOperation is never handled.
  // In some older Node.js versions or specific libraries, this unhandled promise rejection
  // could lead to subtle memory leaks if the promise infrastructure doesn't clean up properly.
}

The await keyword pauses execution until the promise it's waiting on settles. But what happens if you have multiple await calls and an error occurs between them, and one of those subsequent promises isn't explicitly handled or chained correctly? In some scenarios, particularly with older Promise implementations or certain error propagation patterns, these unhandled promises can remain in memory. They’re not actively doing anything, but they’re not being garbage collected either. Over millions of invocations, this adds up. We saw this in a microservice responsible for user profile updates. It was using Promise.all with a series of await calls within async functions. When one of the awaited operations failed after its promise had resolved but before the next await could catch it, that promise object persisted. Node's V8 garbage collector couldn't reclaim it, and our heap grew by megabytes per hour. We eventually tracked it down using heapdump and node-memwatch (versions 0.3.4 and 0.4.0 respectively), identifying specific Promise objects that were unexpectedly retained.

The Promise.all Pitfall: Not Just About Performance

Everyone knows Promise.all is great for running multiple promises concurrently. But the common mistake isn't just about performance degradation when one promise is slow. It's about how errors are handled, or not handled, when one promise rejects.

Consider this pattern:

async function processBatch(items) {
  const results = await Promise.all(items.map(async (item) => {
    const processedItem = await processSingleItem(item);
    if (!processedItem.isValid) {
      // This error will cause Promise.all to reject immediately.
      // The other promises in the map might still be running, but their results
      // or even their potential errors won't be seen because Promise.all short-circuits.
      throw new Error(Item ${item.id} is invalid.);
    }
    return processedItem;
  }));
  return results;
}

If processSingleItem throws an error, Promise.all rejects. This is expected. However, if you have a complex Promise.all where you’re not carefully catching errors within each mapped async function, you can end up with unhandled promise rejections that might not immediately crash your application but can contribute to memory bloat. We had a reporting service that used Promise.all to fetch data from three different external APIs. One API was intermittently flaky. When it threw an error, Promise.all would reject. We had a top-level try...catch around the Promise.all call, but we weren't explicitly handling the individual promise rejections within the map. This meant that sometimes, the promise object from the flaky API, even after rejection, would linger in memory because the rejection wasn't fully "consumed" by our error handling logic. This was particularly problematic in our older Node.js v14.17.0 instances, where the garbage collector seemed less aggressive with lingering promise objects.

The Unseen Cost of async Function Return Values

Every async function, by definition, returns a Promise. If you call an async function but don't await its result, or at least attach a .then() or .catch() handler, that promise object is created and then potentially orphaned.

This is a classic mistake for newcomers:

async function initializeService() {
  console.log("Initializing...");
  await new Promise(resolve => setTimeout(resolve, 1000)); // Simulate work
  console.log("Initialized.");
  return "Service Ready";
}
// Later in the code...
initializeService(); // Oops! We forgot to await this.

In a simple script, this might be fine. In a long-running server process, especially during startup or when registering event handlers, forgetting to await or .then() an async function call can lead to a buildup of these unhandled promise objects. We saw this in a background worker service that was designed to spin up multiple worker instances. Each worker initialization was an async function. Due to a copy-paste error, one of the calls to initializeService() was made without await. This single forgotten await led to a small, but persistent, memory leak on each worker startup. Over time, with many workers coming and going, it was enough to cause performance degradation. The fix was as simple as adding await before the offending initializeService() call, but finding it required digging through dozens of initialization routines.

What I would do differently if I started today. I'd embrace async/await but with extreme prejudice. I’d use a linter rule (like eslint-plugin-promise with strict settings) to flag any unhandled promise rejections or forgotten awaits. I’d also be far more aggressive with try...catch blocks, ensuring that every await is within a try...catch or that the promise chain itself has a .catch() handler attached. For Promise.all, I'd strongly consider using Promise.allSettled if I needed to know the outcome of all promises, regardless of whether some rejected, rather than Promise.all which short-circuits. This provides more granular control over error handling and prevents orphaned promises in failure scenarios.

What this looks like for your team.

1. Static Analysis is Your Friend: Implement and enforce strict linting rules for promises. Tools like ESLint with eslint-plugin-promise can catch many of these issues before they hit production. Make it a gate in your CI/CD pipeline. 2. Structured Error Handling for async/await: Every await should be within a try...catch block, or the promise it’s awaiting should have a .catch() handler. This ensures that promise rejections are always "observed" and handled, preventing them from lingering in memory. 3. Consider Promise.allSettled: When you have multiple independent asynchronous operations and want to know the outcome of each, Promise.allSettled is often a safer bet than Promise.all. It doesn't short-circuit on rejection, giving you a clearer picture of what happened with every promise.

I write about engineering decisions and production systems at devwithzach.com — drop me a line if any of this rings true.