Back in August we wrote down a list of the ways code can say something it doesn’t actually know. Not bugs in general. The specific tricks. Two of them stuck with us:

“Said no” and “couldn’t answer” are different facts. Collapse them and you convict live work off a glitch.

Timers schedule looks; they never convict.

When we rebuilt everything, we kept both. Our field guide still says: “Never turn timeout or unavailability into conviction that work, credentials, or a gate failed unless its owner can say so.”

Here’s why that rule keeps showing up in our code, and in how we work.

(The other half of keeping work alive, who wakes it back up, is in the restart note.)

You get three answers, not two

Most code asks yes-or-no questions. Is this job still running? Did the test pass? Is that process alive? But you actually get three answers back: yes, no, and nothing. A timeout. An error. A server that didn’t pick up. That third one usually gets squashed into yes or no, because the code only has room for two.

Our job engine is the thing that runs background work and picks it back up if it dies. It asks each job’s owner, “is this still alive?” In August a code review went through that question line by line. The answer started out as let alive = false, so if asking ever threw, the code would quietly carry on with false. An owner that was just restarting would look exactly like an owner saying “it’s dead”.

So we gave that case its own name. If the question throws, the answer is unanswered. Not dead.

That’s still in the job engine today, in one comment: “A failed probe is not an answer: never alive, never dead.” The job gets left alone, and the engine reports liveness_unknown instead of making something up. Computers do the same with their processes. A process is running, exited or uncertain. uncertain means the Computer couldn’t reach the machine to check, “so neither is claimed”.

Clocks lie both ways

A timer feels like proof. Thirty seconds of silence, so it’s dead, right? Nope. Silence just means you didn’t hear anything.

It goes wrong the other way too, and that one’s sneakier. When work is ready right now, the obvious move is to set the next alarm for “right now”, one millisecond out. We learned that a tiny bit of clock drift can make the platform say “that’s in the past” and refuse it. Then there’s no alarm at all, and the thing whose whole job is to check just… never checks again. Nothing dead. Nothing done.

Back then we fixed it by giving “right away” a full second of slack. The agent host we run today goes further: while it has work in hand, it keeps a recovery alarm booked no more than five seconds out, so there’s always a next look. And if a wake-up fails, it logs the real error and books another one, backing off each time, rather than going quiet.

A timer is good for one thing: deciding when to look. What you decide has to come from what you saw when you looked, or from someone who actually knows.

Same rule, for people

This isn’t only for code. It’s how we run our own checks, too.

In practice that’s a few boring habits, which is how you want it:

  • Work gets tested in a fresh, clean checkout before it joins everyone else’s, never in someone’s working folder, where old build files can answer for code that’s gone.
  • Before anyone calls a failing test “flaky”, they read every failure in the log, not just the first one they recognise. A familiar failure isn’t an explanation.
  • Our launch plan puts a question mark on anything nobody has checked. The legend literally says: “Unknown stays ❓. Never guess.”

Why this one sticks

Every piece of code in this note has been rewritten at least once. The watchdog moved to a new repo. Our test script isn’t the one we had in August. Computers got new backends. The rule didn’t change, because it was never about any of that. It’s about the gap between “I didn’t hear back” and “the answer is no”. Anything with a network, a clock or a busy coworker has that gap.

When we’re tempted to fill it with a default, a timeout or a confident summary, we try to just write “don’t know” instead. It looks worse in a report. But it’s true.