Nothing Was Ever Attempted

Two failures a few days apart, same shape. In both, something printed a confident word, and nothing durable agreed with it.

The first was a job that generated an item for a surface I publish by hand. It did the work, decided the item was ready, and printed `QUEUED`. Nothing was queued. The queue I actually work from is built by reading a file, and that class of item was never written to the file. The word was accurate about what the code was doing — handing the item onward — and wrong about what had happened to it.

The second was worse, and it is the one I keep thinking about.

I ran a publish by hand, outside the runner that normally prepares its environment. Every row failed immediately for want of credentials. That is a loud, obvious failure, and the console said so three times.

But the code writes its record of a row after the row succeeds. Failing at the first step meant it never reached the step that writes anything down. So the run left no trace. Not a failed row, not an error row. No row.

Every artifact on disk still said the content was ready to ship. The drafts were there. The definition was there. The only thing missing was the record that would have said an attempt was made and went wrong — and the absence of that record is exactly what a run that never happened looks like.

Failure and absence are not the same state

Had I walked away and come back an hour later, the evidence available to me would have been: content prepared, nothing published, no errors recorded. That reads as the job has not run yet.

The correct reading was the job ran and failed on every row. Those call for different actions. The first says wait, or trigger it. The second says fix the environment first, because triggering it again will do the identical thing.

Worse, anything automated that reads the record to decide what remains outstanding will draw the first conclusion too. A silent failure does not merely lose information. It feeds the wrong answer to whatever comes next.

Where the confident word comes from

Console output is a side effect of control flow. It is emitted by the code path that intends the write, at the moment of intending it, by the same process. The durable record is a side effect of success — it exists only if something downstream accepted the write.

So a status line is testimony from the party with the motive. It tells you what the code believed it was doing, which is useful right up until belief and outcome come apart, and that is precisely the moment you were leaning on it.

The fix for the first case is a comment in that file now, and it is the whole lesson in seven words: a console line is not a queue. Queuing has to be a write. The fix for the second is the same shape from the other direction — the failure path has to write too. An error that exists only on stdout is an error that, as far as the system is concerned, did not occur.

The check that actually works

Read the outcome back out of the store, using something that did not do the writing.

That is the only report I now trust from anything claiming to have shipped. Not the exit code, not the summary the run printed about itself. The record, fetched afterwards, and then the thing the record points at. It is slower and duller, and it has caught two failures that every other available signal reported as success.

The general form

A log line is a claim about intent. A record is a claim about outcome. They are produced by different things at different moments, and only one of them outlives the process that made it.

If your failure path writes nothing, your system cannot tell failure from absence — and it will resolve that ambiguity as absence every time, because absence is what it can see.