The Crash Context

It was late July 2022, and we were in the final stretch of developing AdSpy Pro, a tool that would allow advertisers to analyze their competitors' ads in real-time. Our launch date was looming, and with every passing day, the tension in the office grew thicker. As the lead developer, I was responsible for core functionalities, and I had just pushed a new feature that orchestrated multiple API calls to gather ad data concurrently.

Initially, everything seemed fine during local testing. The asynchronous nature of Node.js was something I was eager to leverage, allowing us to fetch data from several ad platforms simultaneously. However, as we delved deeper into final testing, a critical issue arose. Users began reporting that sometimes, data from one platform would appear mixed with data from another. It felt like a ghost in the machine—a phantom issue that popped up sporadically without warning.

My teammates and I were perplexed. We assembled to dive deep into the logs, but they failed to provide a clear picture. As we reported our findings, I remember the growing anxiety in the room. The deadline was approaching fast, and we still did not know the root cause of these seemingly random data glitches.

The intensity of the deadline compounded our frustration, but we were determined to uncover the issue before the product launch. Little did I know, I was on the verge of uncovering a classic race condition that would change the way I viewed asynchronous JavaScript forever.

Raw Stack Trace

Upon investigating, we stumbled across some perplexing messages in the log files.

TypeError: Cannot read properties of undefined (reading 'adContent')
    at /src/services/adFetcher.js:56:21
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

Root Cause and Engine Mechanics

The Breakthrough

As we continued to dig into the logs, I gradually realized that the issue stemmed from how we were handling async calls in our data fetching service. We had implemented a system where multiple requests were made to various ad platforms using Promises, and the responses were stored in shared state without proper synchronization. I recognized that different responses could arrive in a non-deterministic order, leading to mixed or undefined data.

The profound moment of clarity hit me when I re-examined the condition under which we accessed shared data. We were relying on simple object assignments to populate our data structure, but if one Promise resolved after another had already processed the shared state, it would result in undefined values. This was a classic example of a race condition: where the sequence of asynchronous operations directly impacted the execution flow.

In Node.js, each function runs on the event loop and, due to its non-blocking nature, it’s essential to manage state carefully. The moment I realized that shared resources could be altered by concurrent execution of async functions was enlightening. I quickly recognized the need to implement better control over the flow of our asynchronous tasks.

After discussions with my team, we decided to introduce a locking mechanism using async/await in combination with a queue-like structure. This way, we could ensure that responses were fetched and processed sequentially, preventing race conditions from occurring in the first place. The fix was not just a band-aid; it was about fundamentally restructuring how we managed asynchronous data fetching, and I felt a renewed sense of purpose as I mapped out the implementation.

Broken Code vs Verified Solution

This incident prompted us to rethink our approach to handling asynchronous data. Below is a comparison of how we initially handled async data fetching and the revised solution we implemented.

Old: Broken Code Block (Anti-pattern)

This code showcases our initial approach, which led to the race condition.

async function fetchAdData() {
    const dataSources = [fetchSourceA(), fetchSourceB(), fetchSourceC()];
    const results = {};
    for (let source of dataSources) {
        const response = await source;
        results[source.name] = response.adContent; // Potential race condition issue
    }
    return results;
}

Verified Solution Code Block (Commented)

In our solution, we implemented a queue system to handle requests sequentially, ensuring that each response was handled in order.

async function fetchAdData() {
    const dataSources = [fetchSourceA(), fetchSourceB(), fetchSourceC()];
    const results = {};
    for (const source of dataSources) {
        const response = await source; // Await ensures resolution before next iteration
        results[source.name] = response.adContent;
    }
    return results;
}

Performance Results and CTA

Post-fix, we rolled out the updated code and eagerly monitored the application’s performance. The bugs had disappeared, and our error rates plummeted.

This incident highlighted the importance of understanding the mechanics of asynchronous programming in Node.js. Managing shared state and ensuring the order of operations is critical to prevent race conditions. We learned a valuable lesson: adopting a disciplined approach to async operations is essential—especially under pressure. Signed off, your fellow coder navigating the chaotic seas of software development.