Changelog — 2.262–2.264
Releases 2.262.0 through 2.264.3. Current releases are on the main changelog, and every band is listed in the release archive.
Loading audio...
Version 2.264.3
September 3, 2026Our release checklist was sending us to nine machines that needed nothing
- Nothing you can see has changed. This is the tool that walks us through publishing a new version of the site.
- It works out which machines need updating by looking at which files changed. Recently we edited one shared setting across every machine’s build recipe at once — and each recipe watches itself for changes. So all of them reported as changed, and the checklist dutifully produced instructions for nine machines with nothing to install.
- A checklist that is mostly noise is worse than a longer one, because it teaches whoever is following it to skim — and skimming is how a machine that did need attention gets missed. It now separates the two, and still names every machine it set aside, with the reason.
- It refuses to decide silently. Editing a build recipe genuinely can change what gets installed, so nothing is dropped without being mentioned.
- Writing the fix, our own test caught a flaw in it. The first version could never have printed its explanation at all — for a reason invisible in the output, since the explanation simply wasn’t there to look wrong. It surfaced as three unrelated failures elsewhere.
- We also corrected yesterday’s tidy-up of this page. Older entries were filed into the archive slightly too eagerly: two of them had not yet appeared here at all, so they would have been published and archived in the same breath. They are back, and will be filed away once they have had their turn.
- Nothing to do at your end.
Version 2.264.2
September 3, 2026A small label on an internal page split itself in half
- Nothing you can see has changed — this is an internal page, tidied.
- A two-word label wrapped onto a second line, and because it sits inside a rounded coloured badge, the badge wrapped too: two half-pills stacked instead of one.
- It only appeared once yesterday’s fix started working. That column had been showing a dash while the check underneath it could not complete, so its longest label had never actually been drawn. A space only has to be big enough for what it has so far been asked to hold.
- Fixed on every badge of that kind, not just the one in the screenshot. Six others shared the same flaw and had simply been lucky with shorter words.
- We also filed the older entries away. This page was getting long enough to be slow, so everything from 2.253 to 2.261 now lives on its own page, reachable from the archive. Links to individual older entries still work and land in the right place.
- Nothing to do at your end.
Version 2.264.1
September 2, 2026An internal status page said “unknown” about something that was working perfectly
- Nothing you can see has changed. This is an internal monitoring page, and it was wrong in the direction that matters least on a good day and most on a bad one.
- It watches the security credentials our machines present, so that one quietly expiring gets noticed before it stops something. One entry read “unknown” — which looks identical to a machine being switched off.
- The check was asking the wrong question. It knocked on the door using a numeric address, when the machine behind it decides which credential to show based on the name you ask for. Given no name it recognised, it declined to answer at all — correctly, but in a way that read as a fault.
- The check now asks by name, and the fix is arranged so that whoever adds the next machine cannot forget to, with a test that fails if they do.
- A warning we would otherwise have read past turned out to matter. Buried in the output was a note that the old way of asking is being retired by the underlying software, and would eventually stop working everywhere rather than in this one place. So a small fix quietly closed a much larger future problem.
- Nothing to do at your end.
Version 2.264.0
September 2, 2026Builds now fetch the code from the next room — and quietly take the long way if they can’t
- Nothing you can see has changed, but this is the payoff of the last two notes, and the first one that actually saves any time.
- The short route existed but nothing was using it. We built it, proved it worked, and then found that every build still asked for the code by the old address out of habit — because that address is handed to the build by the system itself, not chosen by us. A road with no traffic on it.
- Builds now check whether the short route is answering, and use it only if it is. Fetching the code takes roughly a tenth of the time it did. If the short route is unavailable for any reason at all, the build takes the old one instead, silently.
- We proved the fallback by breaking it on purpose rather than by reading the code and trusting it. With the short route deliberately pointed into a black hole, the build waited five seconds, gave up, went the long way, and finished normally. A safety net nobody has ever dropped a weight onto is not known to hold.
- The obvious way to do this would have broken every private fetch. The permission a build uses to collect code is tied to the exact address it was told to use; redirect the address and the permission stops matching, which fails as a mysterious network error rather than an obvious refusal. So we kept the address and changed only where it points.
- It also gives up rather than fails in three other situations we can think of, because a build breaking over an optimisation would cost far more than the optimisation saves.
- Nothing to do at your end.
Version 2.263.1
September 2, 2026The secure internal route we announced yesterday could not actually obtain its credential
- Nothing you can see has changed. Yesterday’s note described a secure internal route for our build system. This is the work that made it actually function — it did not, and the reason was ours.
- It failed at the final step, and the error blamed the wrong party. Obtaining a publicly recognised credential means publishing a short-lived public note and then confirming the note is visible. Publishing worked perfectly. Confirming did not — and the message it produced pointed at the service issuing the credential, which had done nothing wrong.
- The cause was our own network answering a question we had addressed to the outside world. When our software asked a public directory whether the note had appeared, the reply came from inside our own network instead, where that name is handled separately and the note therefore did not exist. Every check we ran agreed with every other check, because all of them were being answered by the same wrong source.
- What settled it was asking a question with an impossible answer. We asked a public directory about a name that exists only inside our network. It answered — which it could not possibly do, unless something closer to home was replying on its behalf.
- The note itself was fine throughout, visible to the outside world within about eight seconds of being published. Only our own pre-flight check was blind, so that check is now switched off rather than trusted.
- A second trap cost time on the way, and it is the more general lesson: the configuration file we were editing was not the file the software was reading, and every tool we used to inspect it reported cheerfully on the stale copy. Agreement between instruments is not evidence when they share a source.
- Nothing to do at your end.
Version 2.263.0
September 2, 2026Our build system was fetching the code from across the country, when it was in the next room
- Nothing you can see has changed, but this is the fix for why building the site got dramatically slower yesterday.
- Every time we build the site, the machine doing it has to fetch a copy of the code. That code lives on a machine a few feet away — but the address it was asking for pointed out to the internet and back again. So the code was leaving the building and returning, every single time.
- For a long time that cost seconds and nobody noticed. Then our internet connection developed a fault in one direction, and the same fetch went from about twenty-five seconds to nearly ten minutes. Same code, same machines, same distance — only the detour changed.
- The fix is not to make it faster. It is to stop going outside at all. The build machines now reach the code directly, and a bad day on our internet connection stops being a bad day for building the site.
- The interesting part was doing that securely. Machines refuse to talk to each other over an encrypted connection unless they recognise the credential being presented, and the credentials we issue ourselves are not recognised by the temporary environments our builds run in. So we obtained a proper, publicly recognised one — for an address that only exists inside our own network and cannot be reached from outside at all.
- That is possible because of how the proof works. The usual method requires the outside world to connect to you, which would mean opening a door. The method we used instead proves you control the name by publishing a short-lived note in public records. Nothing connects inward; no door is opened.
- We also made sure this cannot expire unnoticed. These credentials renew themselves every couple of months, and a silent failure would only show up when everything stopped — so their expiry dates are now watched alongside everything else.
- Nothing to do at your end.
Version 2.262.0
September 2, 2026Our own setup guide sent us to a machine that was thrown away weeks ago
- Nothing you can see has changed. This is behind-the-scenes work, written up because of what it found.
- We added a new machine that will store our own copies of the software we build, so that publishing and deploying stop depending on the public internet.
- Setting it up broke our own instructions three times. The guide was written while building a different kind of machine, and quietly assumed that kind everywhere. Three of its four commands simply do not work on the sort we were building. All corrected, along with a better way in that needs no password at all.
- A guide that is right once and wrong afterwards is the expensive kind, because it is trusted. It now says which steps apply to which kind of machine.
- And a check we built last week found something nobody was looking for. Our records still listed a machine that was decommissioned weeks ago — and worse, our own troubleshooting notes named it as the one to connect to. Anyone following them would have spent a while wondering why nothing answered.
- The reason it was found is the check asks the question backwards. The obvious version goes down a list and asks whether each thing is set up. A list cannot report what it does not mention. This one starts from everything that exists and asks whether the records know about it — which is the only way that particular ghost was ever going to turn up.
- Nothing to do at your end.