The Crash Context

It was October 15, 2023, and I was deep in the trenches of TheDevDude, a real-time communication platform we were set to launch in just three days. The team was buzzing with anticipation, but also a palpable tension - the deadline loomed large, and we were racing against time to finalize features. I remember we were implementing a critical WebSocket connection to facilitate real-time updates for user notifications, an essential part of our user experience.

On this particular day, I was testing the notification service with multiple concurrent users. As I monitored the server logs, we suddenly encountered a spike in errors. The application intermittently crashed, throwing a runtime exception that we had never seen before. My heart sank; the deadline was looming, and we had to pinpoint the cause of these crashes before our launch.

The actual error seemed scattered across different log entries, and while I was initially grasping at straws, I soon realized the issue might be related to how we were handling WebSocket message events. Each event was supposed to call a dedicated handler, but the server was crashing under the weight of multiple simultaneous requests, leading to chaos. I felt the weight of responsibility on my shoulders as I dove into the investigation, unaware of the actual root cause.

As I dug deeper, I knew we needed to identify what was causing the WebSocket connections to fail. Each crash brought us closer to missing the impending launch deadline. The intensity of the situation began to sharpen my focus, and the clock was ticking.

Raw Stack Trace

This stack trace provided critical insights into the runtime exception:

TypeError: Cannot read properties of undefined (reading 'send')
at WebSocket.onmessage (websocketHandler.js:45)
at WebSocket._dispatchMessage (websocket.js:112)
at WebSocket.onmessage (websocket.js:140)

Root Cause and Engine Mechanics

The Breakthrough

As I scrutinized the stack trace, the mention of 'Cannot read properties of undefined' triggered an epiphany. The error indicated that we were attempting to access the 'send' method of an undefined WebSocket instance. I recalled that our handling of user objects was done conditionally, which could lead to some users not having valid socket connections under high load.

Upon further investigation, I traced the issue back to our message handling logic in the websocketHandler.js file. In our attempt to broadcast messages to all connected clients, we had written a loop that inadvertently assumed every user had an active WebSocket connection. When multiple messages were dispatched simultaneously, some connections would timeout or drop without proper error handling, leading to the observed runtime exceptions.

This pattern was particularly problematic since high-frequency events—like new notifications—could flood our WebSocket server, overwhelming it. The mechanics of WebSocket handling dictated that each message must be sent through a valid, active socket connection. Any lapse would lead to the runtime exceptions we were facing.

The aha moment was realizing that we needed to build more robust error handling around our WebSocket connections. This would not only prevent the crashes but also allow for a better user experience during peak activity periods.

Broken Code vs Verified Solution

Upon identifying the flaw, we made necessary adjustments to our code by implementing checks for valid socket connections before sending messages.

Old: Broken Code Block (Anti-pattern)

This code snippet reflects the problematic implementation:

const sendNotifications = (users, notification) => {
  users.forEach(user => {
    user.socket.send(JSON.stringify(notification)); // Potential TypeError
  });
};

Verified Solution Code Block (Commented)

Here’s how we corrected this behavior with proper validity checks:

const sendNotifications = (users, notification) => {
  users.forEach(user => {
    if (user.socket && user.socket.readyState === WebSocket.OPEN) {
      user.socket.send(JSON.stringify(notification)); // Safe send
    } else {
      console.warn('Socket is not open for user:', user.id);
    }
  });
};

Performance Results and CTA

After implementing the fix, we monitored the application's performance closely:

With the new handling checks in place, we not only eliminated the runtime exceptions but also enhanced the overall responsiveness of our real-time app. The lesson learned was that in WebSocket implementations, managing connection states and error handling is paramount, especially when facing high concurrent loads. We were able to launch TheDevDude successfully on schedule, and the experience reinforced my appreciation for robust error handling practices. Until next time, happy coding!