When your logs lie (and there's a ghost in your machine)

Earlier I was of the opinion that learning and implementing new tech stack takes dedication and is not an easy thing to do. But now I think that debugging can be a much harder thing to do because of what happened with me recently.

A simple error and missing logs

It all started with a TypeError: Cannot read properties of undefined (reading 'refreshToken')in my Node.js backend. A common error, one I previously encountered multiple times. I was trying to test a feature with the postman , which wasn’t working. I tried a couple things before i sprinkled the console.log statement in my changeCurrentPassword component. To my surprise I found there wasn’t a single log in the terminal. I checked the previous component which were working fine, put some console statements there as well, fired up the postman, and the endpoint was working, 200 OK status code. But the terminal was silent.

Diving deep into the spiral

This is where the fun began. I thought, I’m new to this technology, maybe I’m doing something wrong , but still a simple console log? Then I considered some more scenarios:

• Middleware Malfunction: Was my asyncHandler tweaking or my verifyJWT silently failing? I put logs everywhere in these components but still nothing occured on the console even when the requests were hitting. This was something that had never happened to me.

• Module Loading Order: I learned that app.js (where my Express app instance and global middlewares were defined) was being loaded before my database connection logs from index.js. This revealed that Node.js executes imported modules entirely before resuming the importing module. While a normal behavior, it hinted at module loading complexities.

• The "Circular Dependency" Rabbit Hole: I got across the concept of circular dependencies – where A imports B, and B imports A back. This can lead to modules being loaded multiple times, creating different instances of your app object. I added console.log(app === global.myAppInstanceCheck) statements. The result: app in app.js was false, but in index.js it was true. This was a huge clue! It confirmed that the app object configured with all my middleware (and logs!) wasn't the exact same object that index.js was listening on for requests.

• 

I was relieved for a moment, at least then I knew what the error is and I could somehow find a way to figure it out. Despite manually searching for any extra import {app} from “./app.js” statement , I didn’t find it any of the components. How could the app work, postman send 200, OK status code and message yet I didn’t have any console.log statements

Ghost in the Machine

I ran to GPT to figure out the issue, I had already tried most of the things it enlisted in suggestions. After some detailed conversation regarding my issue, it suggested to check if i was running multiple node.exe processes on the same port. I hadn’t though of it. Looked for the command and ran it , taskkill /f /im node.exe . This was it. I wasn't dealing with a single, misbehaving application instance. I had a ghost process running in the background – an older instance of my Node.js server that had never properly shut down. When I was starting my server, my terminal would say "Server running on port 8000." This was the new instance. But all my Postman requests were actually being routed to the old, lingering process that was still listening on port 8000. Since that old process didn't have my latest console.log statements , all my debugging efforts went into vain. The new server was just sitting there, silently accepting no traffic, lol.

At the end, I was happy. The process wasted a huge chunk of my day but at least I learned couple new things which may benefit me in the future. That’s when I realized that debugging can take you down unexpected paths. Sometimes, the most frustrating problems aren't about complex code, but about a simple, silent ghost lurking in your system.