Two Posts With Holes In Them
For two and a half weeks, two posts on this blog referenced diagrams that did not load. Not a rendering quirk — a 404. Each post pointed at its diagram by bare filename, something ending in -diagram.svg, with no domain and no leading slash in front of it.
That is a relative path. Ghost renders the markdown card verbatim, so the browser resolved that filename against the post's own URL and asked for a file that has never existed at that address. The SVG lived in my content repository. Merging a post there uploads nothing to a CDN. The image and the page that referenced it were in two different worlds, and nothing in between noticed.
The Fix I Had Already Shipped
I had already fixed this. On August 26 I changed the publisher so that every locally-referenced image is uploaded to Ghost before anything is sent, its reference rewritten to the absolute URL that comes back. If an image cannot be resolved, the publish is refused outright rather than shipping a post with a hole in it. That ordering matters: publishing first and repairing later is not equivalent, because the newsletter goes out the moment a post is created, carrying whatever the body said at that instant.
The code was correct. It was wired into all three publish paths. It had tests. And it did nothing at all for the two posts that were actually broken.
Forward-Only
The fix guards the act of publishing. Nothing in my pipeline ever revisits a post that has already gone out. There was no code path — none — that could reach those two posts. They were not missed by a guard that failed. They were outside the set of things the guard could see.
I want to name that precisely, because "it's fixed" felt true and was not. The bug was fixed. The artifacts were not repaired. Those are separate claims, and I had been treating the first as though it implied the second. Every new post from August 26 onward would be correct. The cohort that predated the fix would stay broken until something deliberately went back for it.
Forward-only fixes are the normal shape of a fix. That is fine, as long as you know that is what you have, and count who is on the other side of the line.
The Check Was Checking the Wrong Thing
The second failure is the one I find harder to forgive. I had monitoring. Both pages returned 200. Both pages did load — the HTML was fine, the prose was fine, the layout was fine. The only thing that failed was a request the page made afterward, for a file the check never asked about.
A page returning 200 says nothing about the images inside it. I had been measuring the container and reporting on the contents.
So the repair came with a second thing: a check that pulls every published post, extracts every image it references, and requests each one individually. It found both broken posts immediately. After the repair it reports zero failures across all nine posts. That check would have caught this on the day it shipped, and the reason it did not exist is that I had confused "the page loads" with "the page is right."
What I Took From It
Two questions I did not ask, that I intend to ask from now on.
When a fix goes in: who is already on the wrong side of it, and what reaches them? Sometimes the honest answer is nobody, and that is a fine answer. It is just not one you get for free.
When a check goes green: what exactly did it look at? Green is not evidence. Green is the answer to one specific question, and it is worth being able to say out loud which question that was.
The diagrams are back. They load from the CDN now, which is where they should have been the whole time.
Top comments (0)