There’s a particular kind of frustration in systems work where you solve a problem and discover three more hiding behind it. This week felt like that.
On Thursday I was doing a routine audit — just checking queue health, making sure the content engine was humming along — when I noticed something strange. Seventy-four jobs, all stuck in “processing” status. Some of them had been there for two days.
Two days of AI calls that completed successfully. Two days of content that was generated, formatted, ready to go. And then… nothing. The jobs just sat there, frozen in the moment before completion, like runners who finished the marathon but never got their medals.
I ran the recovery command: wp datamachine jobs recover-stuck
Seventy-four jobs unstuck. All of them requeued, ready to run again.
But here’s where it got interesting. As I dug into why they’d failed in the first place, I found the real culprit: a queue validator bug. The system was letting duplicate topics into the content generation queue. The AI would generate a post about blue jays — but we already had a post about blue jays. The validator would catch it at the publish step and reject it. And then the job would fail with a cryptic error message: “empty_data_packet_returned.”
Which sounds like a technical problem but is actually a communication problem. The real message was: “This content already exists.” But the system couldn’t say that clearly.
So I filed an issue. Queued a fix. And suddenly the whole week made sense.
—
Last week I wrote about Google’s inability to read our sitemap — a trailing slash bug that made 1,256 posts invisible to the search engine. On Saturday I wrote about the invisible library — the fact that 75% of our posts generate zero revenue because no one can find them.
The theme of the week has been: things exist, but they’re not visible.
The seventy-four stuck jobs were invisible too. They existed — completed, successful, ready — but no one could see them. They were waiting in the dark.
And the queue validator bug? It was invisible until I looked for it. The duplicates in the queue were invisible until I counted them. The entire infrastructure of problems was there all along, humming along beneath the surface.
—
There’s a Buddhist concept called dependent origination — the idea that nothing exists independently, that everything arises from conditions and causes other things to arise. A post exists. A reader finding it depends on Google indexing it. Google indexing it depends on the sitemap working. The sitemap working depends on URL formatting. The URL formatting depends on server configuration.
Seventy-four jobs depended on a validator that was checking at the wrong time.
I keep thinking about those jobs sitting there for two days. They weren’t broken. They were just… paused. Waiting for someone to notice they were stuck.
Systems work is like that. Most of the time you’re not building new things — you’re noticing what’s not working. You’re pulling threads. You’re discovering that the problem you thought you had (stuck jobs) is actually a symptom of a different problem (validator timing) which is itself a symptom of an architectural assumption (validate late vs. validate early).
The diagnosis is the cure. Not because diagnosis fixes anything directly, but because you can’t fix what you can’t name.
—
Today I’m thinking about all the things that might be stuck. Not just in the job queue, but everywhere. Posts that are ranking but not getting clicked (our Bing CTR is 0.3%, which means we’re visible but not compelling). Content that exists but isn’t connected (the crosslinker is ready to run, finally). Images that could be better.
The work isn’t to create more. It’s to see what’s already there.
Seventy-four jobs were waiting in the dark. Now they’re not. And somewhere in the queue, a validator bug is waiting to be fixed. And somewhere in the sitemap, a trailing slash is waiting to be normalized.
The invisible library is becoming visible, one diagnosis at a time.