This blog could not tell you it was broken

This blog had a neat failure mode: every post could disappear and the deployment would still be green.

CosmicGlue is statically built. During a deploy, Astro asks JamWidgets for the published posts and turns them into pages.

If the site key was missing, the loader returned an empty list. If JamWidgets returned an error, it logged a warning and returned an empty list.

Astro did exactly what it was told. It built a valid site containing “Nothing published yet.” The deploy uploaded it. The server returned 200.

The content pipeline was dead, but from the outside the blog merely looked unpopular.

That is worse than a failed build. A failed build leaves the previous site online. A successful empty build replaces working pages with an error disguised as content.

The obvious fix was to fail when production cannot load posts. The annoying part was deciding what “production” meant.

Astro’s production flag was not enough. CI runs the content loader in production mode too, and that job deliberately does not have the JamWidgets key. Checking CI was worse because the real deploy also runs in CI.

So the deploy now says what it is:

DEPLOY_BUILD=1

During an actual deploy, missing credentials or a failed content request stops the build. During ordinary verification, the loader can still run without production secrets.

It is a boring flag. I trust boring flags more than clever environment detection.

The larger bug was treating “I found zero posts” and “I could not ask for posts” as the same result. Empty data is still data. An unavailable dependency is an error. Turning both into [] made the code pleasant and the system dishonest.

Now an empty blog means JamWidgets returned an empty blog. If JamWidgets cannot answer, the last good version stays online.

Red builds are annoying. Green lies are worse.