It's Not Always Named as It Sounds, The Array.prototype.every() Story

Some bugs you fix in five minutes. Others teach you something you never forget. This one cost me a full day of focus - four straight hours locked onto a single bug, and a production night around it. It also changed how I read code forever.

This is a true story.

The bug that only lived in production

It started on a crisis night. A bug appeared in production - but only there. Not in every case, just in some scenarios. And no matter what I tried, I could not reproduce it locally.

I had everything: the production logs, the exact inputs, the scenario details. I fed the same data into my local environment, ran the same path, and... it worked perfectly. Every time. Meanwhile, production kept failing.

That's the worst kind of bug. When you can't reproduce it, you can't see it. You're debugging a ghost.

The function at the center

Somewhere in a large module, I had written a function that looked roughly like this:

// ...lots of other code...

function foo(incomingArray: string[]) {
  if (!incomingArray.every(Boolean)) return false;
  // ...other conditions...
}

// ...lots of other code...

The intent was simple. Before running my logic, I wanted to make sure the array was "good" - that every item in it was a real, non-empty value. If any item was empty, bail out and return false.

At least, that's what I thought the code said.

Hours of staring

So I started debugging. Line after line. I read the function top to bottom, then bottom to top. I traced every condition by hand.

When that didn't work, I started debugging in my head - running the function like a machine, keeping every variable in my mind, stepping through it the way the CPU would. I went so deep I was practically running a recursive debugger inside my own brain.

Everything looked correct. Literally. I got to the point where I was reading the code character by character, convinced I had a typo somewhere.

Nothing.

Going down to the core

When you've checked all of your own code and it's still wrong, doubt starts to creep in toward the things you normally trust. Maybe I didn't truly understand something. Maybe it was the single-threaded nature of Node.js. Maybe the problem lived somewhere below my code.

So I went down to the core - the built-in JavaScript methods themselves. I started checking every function I was relying on, one by one.

Until I reached that one line:

if (!incomingArray.every(Boolean)) return false;

I stopped and asked myself the obvious question: "Okay - every item in incomingArray is empty. But wait... are they really empty?"

The terminal moment

I opened a terminal, typed node, and started testing my assumption directly:

> ["", ""].every(Boolean)
false

False. Good. That matched what I expected - empty strings are falsy, so every returns false.

But then a different thought hit me. What if the array isn't full of empty items... what if it's empty itself? In plain English, my check was supposed to mean "every item is non-empty, so I'm good to continue." So let me test it:

> [].every(Boolean)
true

True.

That was the moment of shock. An empty array passed my "everything is valid" check. The exact thing I was trying to guard against was sailing right through.

Why it does that

Once I saw it, the reason was simple - and it's hiding in how every actually works. Roughly, the implementation is a loop:

function every(arr, cb) {
  for (const item of arr) {
    // If the array is empty, this loop body NEVER runs.
    // Your callback is never even called.
    if (!cb(item)) {
      return false;
    }
  }
  return true; // So for an empty array, you land straight here.
}

If the array has no items, the loop never executes. Your callback - the part where I was checking for empty values - is never called at all. There's nothing to return false for, so every returns true.

This is called vacuous truth: "every element satisfies the condition" is technically true when there are no elements to check. Mathematically correct. Practically, a trap.

That's why my bug only showed up in production: locally, my test data always had items in the array. In production, some scenarios produced an empty array - and only those slipped through.

The fix

The fix was almost insulting after four hours:

if (!incomingArray.length || !incomingArray.every(Boolean)) return false;

One small !incomingArray.length check. That was it. Crisis over.

The lesson

every doesn't mean "every item passes your test." It means "no item fails your test" - and for an empty array, nothing can fail. The name sounds like it promises something it doesn't.

That day taught me to stop trusting that code means what it says it means. A method name is a hint, not a contract. When something behaves impossibly, drop to the core and verify your assumptions in a terminal instead of in your head.

I won't pretend it didn't get to me. By the end I had dreamed about that module. To this day I could write 500 lines of it blindly. But I never looked at a built-in method the same way again - and I never wrote an every check without thinking about the empty case first.