Correct Code With No Caller

A function that worked

TRON, the security system I run on my own infrastructure, can pause on an action and ask a human first. That request has a deadline: if nobody answers in time, it should stop being live — pending becomes expired.

There was a function for exactly that: give it the current time and it finds every request still pending and past its deadline, and expires each one. Anything still inside its window, or already answered, it leaves alone.

It did that correctly. Nothing about the implementation was wrong.

A test that passed

It had tests, and they were good ones. They created one request already past its deadline and one comfortably inside it, called the function, and checked that the overdue one expired and the live one didn’t. A second confirmed an already-approved request past its deadline was left untouched.

Those tests were not thin and not wrong. They established something real: when this function is called, it does the right thing and only the right thing. The easy version of this story is “the tests lied” — they didn’t. They answered the question they were asked, accurately.

The path that could never fire

Expiry was not missing from the running system. There were two ways an approval could expire, and only one of them had an owner.

The first was reactive, and it worked. When a decision came back for a specific approval, the system checked that approval’s deadline before acting on the answer. Past the deadline, it expired right there.

The second was the sweep — the function above — which could find every overdue request without waiting to be prompted. It had no caller anywhere in the running system; its only callers were its own tests.

Most of the time this stayed invisible: most approvals do get a response, and a response is enough to trigger the reactive path.

But consider which approval most needs an independent deadline: the one nobody ever answered. Then consider why. If the outbound notification never reached a person, no decision would come back — so nothing would ever arrive to examine that approval, and the reactive path had nothing to react to.

The request that most needed its deadline enforced was precisely the one that could never trigger the only mechanism enforcing deadlines. The sweep existed for exactly this case and was never wired to run.

The question the tests never asked

The tests asked does this function work? and answered yes, correctly.

Nobody had asked who calls it?

The function was called expire_all_due(). Its tests called it directly. The running application did not.

That question has an uncomfortable property: inside a test suite, the answer is always “the test does”. Every test of that function supplied its own caller. It was never once invoked by the system it belonged to — and a green suite looks identical either way. Coverage tools would have reported it as covered, because it was.

This is not an argument against testing. It is a narrower point: a test proves the behaviour it exercises and nothing beyond it. It cannot prove the function has a place in the running system, because the test is standing in that place itself.

Giving the behaviour an owner

The fix was not more tests, and not a second implementation.

The daemon already ran a periodic loop for this kind of maintenance. Expiry had no place in it, so it got one: the loop now calls the same sweep function that already existed, once per pass. It can only move an already-pending request to expired — it never executes or sends anything — so nothing needed to gate it.

The behaviour did not change. It gained an owner.

The function already knew how. What was missing was a decision about who is responsible for making it happen. That is an ownership question, not a correctness one — and testing the function in isolation could never have surfaced it.

The consequence was not dramatic, and worth being plain about. A request stayed on the books past its deadline. Execution was switched off at the time and the action ledger was empty — nothing ran, and nothing could have. Pending is not approved, and only approved authorises anything, so the defect left stale state rather than granting permission. Untidy, not unsafe.

What I changed about reviewing systems

Eight tests came with the fix, and one matters more than the other seven. Those seven check the behaviour directly, and are useful — but they are the same kind of test as the ones that already passed.

The eighth starts the real loop with an overdue request already sitting there, and checks the loop expires it. That one is the structural answer: it stops asking only does expiry work and starts asking does the running system actually invoke it.

The habit I took from this is small. When I read code now I trace one step further out: not just is this right, but what causes this to happen, and what if that never fires. It is the question you already ask about error handling, pointed at the ordinary path.

At the time of writing this correction is committed and validated locally against the real loop, but not yet deployed to the live instance — its own small version of the same idea: code that is finished and code that is running are not the same claim.