Changelog — 2.49–2.54

Releases 2.49.0 through 2.54.0. Current releases are on the main changelog, and every band is listed in the release archive.

Loading audio...

Version 2.54.0

August 2, 2026

Long picture-making jobs now survive you closing the tab — and one of them had been quietly throwing work away

  • Some of the artwork our editors make takes a long time. Building the illustrated panels for a Vignette can run for nearly half an hour. Until now, if you closed the tab or your connection dropped, the site had no record that anything was happening at all.
  • Every one of those jobs now keeps a proper record while it runs. That means we can see what is in progress, who started it, and how far along it is — rather than guessing from silence. In most cases the pictures themselves were already being saved safely as they were made; what was missing was any way to know a job existed.
  • One of them genuinely was losing work, and we found the proof rather than assuming it. The step that draws a character from six angles kept all six in memory and only saved them at the very end. If it failed on the fifth, all of it was discarded — roughly ten minutes of work, and a character left half-made that our editors then could not find. We checked our stored images against our records and found a real example from a few days ago. Each pose is now saved the moment it is drawn.
  • A second one was saving nothing at all. The main Vignette illustration existed only inside the browser tab until someone pressed Save. It had escaped notice because of how we check for this sort of thing — our automatic check only looks at jobs that declare themselves as slow, and this one never had. It does now.
  • We also stopped one step deleting an old picture before its replacement had been saved. If the new one failed to upload, you were left with neither. It now saves first and tidies up afterwards.
  • The most interesting problem was one we created by fixing everything else. We keep a list of known shortcuts still to be dealt with, and a test that makes sure the list cannot rot. Clearing the last item off that list left the test with nothing to examine — so it carried on passing while checking nothing whatsoever. Finishing the work quietly disabled the alarm that was watching it. The test now supplies its own example, so it works whether the list is full or empty.
  • Nothing to do at your end. None of this changes anything you see on the site. It is about the tools our editors use, and about making sure a long job that fails says so instead of disappearing.

Version 2.53.4

August 2, 2026

Our own instructions told us to undo a change the wrong way — ninety minutes after we changed it

  • Yesterday’s update gave us a way to put the site back if an update goes wrong. Publishing that very update then printed a note telling us how to undo it — using the old method, which the change we had just made had stopped working.
  • It would have failed in exactly the way it was warning us about. The note existed to prevent an undo that looks like it worked and quietly does nothing. Following it would have produced precisely that. We caught it because we ran the thing and read what it said, not because any check noticed.
  • The same note had already been wrong once before, in the opposite direction. It had been carefully corrected at some point in the past — and the correction wrote down the right answer as though it would stay right forever. So we have stopped it stating an answer at all: it now checks how the site is actually configured and prints whichever instruction is true.
  • We fixed two places in our own handbook that had drifted from reality. One implied that behind-the-scenes work does not need writing up here, which stopped being true months ago — and it misled us that same afternoon into nearly publishing a change with no note at all. The other described this page as being split into two parts when it is now split into ten.
  • In both cases we removed the written-down answer rather than updating it. A summary that repeats a fact kept somewhere else is a copy, and copies drift — this one had gone stale within two days of the thing it described changing. It now points at the command that works the answer out.
  • Nothing to do at your end. None of this touched the site itself. It is housekeeping on the tools we use to look after it — the sort that only ever gets found by using them.

Version 2.53.3

August 2, 2026

If an update ever goes wrong, we can now put the site back to how it was

  • Until now, we could only go forwards. When we published an update, the site was told to run “the newest build” — with no way to say “go back to the one before”. If an update had caused a problem, undoing it would have meant editing settings by hand on the live server, in the middle of the problem. That is the worst possible moment to be doing delicate work.
  • Now every release has a name, and we can point the site at any of them. Going back is a single, ordinary instruction that we have written down and can follow calmly.
  • We deliberately did this on a day when it changed nothing. The version we pointed at was the one already running, so the site served exactly the same thing before and after. That was the whole idea — it lets us prove the mechanism works on its own, rather than mixed in with a batch of other changes where we could not tell what caused what.
  • Pinning a version quietly creates a new way to fail, so we wrote that down too. Now that we name the version, forgetting to change that name means an update appears to succeed while actually changing nothing — every light green, nothing shipped. We already have a check that asks the live site which version it is really running, and running it after every update is now part of the routine rather than a good idea.
  • We found our own documentation saying this was impossible. Our internal instructions stated that named versions did not exist. That was true when it was written and quietly stopped being true months ago, and nobody re-checked. We have fixed it by removing the answer and leaving the command that works it out — a page that tells you how to check ages better than one that tells you what it found.
  • We also removed the last place a person could get it wrong. The version number is now worked out from the release itself rather than typed in by whoever is publishing, and the step refuses to run at all unless it is being run against a genuine release. A small thing, but mistyping a version is exactly the sort of mistake that stays invisible until the moment it matters most.
  • Nothing to do at your end. Nothing about the site changed. This is us making sure that if we ever break something, we can undo it quickly instead of scrambling.

Version 2.53.2

August 1, 2026

When a page is read aloud, web addresses were being read out wrongly — in four different ways

  • Pages on this site can be listened to as well as read. When a page mentions a link, the narration reads out the address so you can find it — and it was getting those addresses wrong.
  • The slash was being read as the word “or”. There is a rule that reads “yes/no” aloud as “yes or no”, which is right — but it was also firing inside web addresses, so a link came out as “our website or changelog”. Addresses are now read properly, with “slash” where a slash belongs.
  • Numbers inside addresses were being read as ranges. A rule that turns “15-30” into “15 to 30” was rewriting part of the address itself, so one of our new pages was announced with a number that does not exist.
  • Version numbers were read inconsistently. “1.0.0” came out as “one point zero point zero” sometimes and “one point zero-point-zero” other times, depending on something a listener could not see. Given this page is largely made of version numbers, that mattered here more than most places.
  • The most useful thing we found was a fix that looked complete and was not. The text is prepared twice on its way to becoming audio. Our first repair worked on the first pass and was quietly undone by the second — and every check we had said it was fixed, because they only ever looked once. We would not have caught that by testing more carefully; we caught it by testing the second pass at all.
  • This part of the system had never been tested before. Every piece of audio the site produces goes through it. It has tests now, and we confirmed they fail against the old code before trusting them.
  • Thank you to whoever listened properly. None of this shows up as an error anywhere — the only way to find it is for a person to listen to a recording and notice that a word is wrong.
  • Nothing to do at your end. Any narration generated from now on reads addresses correctly.

Version 2.53.1

August 1, 2026

A list of “things we still need to fix” was counting five things that were never broken

  • Nothing you can see on the site changed today. This is about how we keep track of our own outstanding work.
  • We keep an automatic check that flags any slow operation which could lose your work if something went wrong. It carries a short list of known exceptions, and that list is supposed to shrink over time.
  • Five of the eight entries on it were not problems at all. They belong to our transcription tools, which have had their own perfectly good way of recovering interrupted work since long before the newer shared one existed. They were sitting on a list that said, in effect, “still to be fixed”.
  • That is worse than it sounds, because it pushes in the wrong direction. Either someone eventually rebuilds a working feature just to shorten a list, or people stop believing the number — and then it stops working for the entries that genuinely do need attention.
  • So the list is now two lists: work still outstanding, and decisions we have made deliberately and written the reasoning for. The count went from “eight outstanding” to “three outstanding, five decided”.
  • We checked the claim before accepting it, and the obvious reading was misleading. Two of the five looked much weaker than the rest on a quick count. Reading them properly showed they do exactly the same thing, just in one step instead of nine. Counting alone would have argued for rebuilding two tools that did not need it.
  • Nothing to do at your end.

Version 2.53.0

August 1, 2026

This page had quietly grown to two-thirds of a megabyte, and everyone visiting it was paying for that

  • The page you are reading was carrying every release we have ever made. All 117 of them, in one page, downloaded in full by anyone who opened it — about twelve times the size of a normal page on this site. It grew a little with every release and nothing ever left.
  • It is now split into bands, and this page keeps only the newest releases. Older ones are grouped by version onto their own pages, listed in the new release archive linked at the foot of this page. The page you are reading is around a twentieth of its former size.
  • Every link anyone has ever shared to a specific release still works. This was the part worth getting right: the bit of a web address after the # is never sent to a server, so nothing on our side can redirect it — a link to a moved release would simply have dropped you at the top of the wrong page, with no error and no clue. Those links are now forwarded in your browser instead, and we tested one for real rather than assuming.
  • We chose where to split by measuring, not by picking round numbers. Some versions had one release, one had eleven. Bands were sized so no single page can quietly grow back into the problem we were fixing.
  • The check that was supposed to guard this page would have gone on passing while looking at a twentieth of it. It read one file, and there are now nine. It was rewritten in the same change to check all of them together, and we deliberately broke it six different ways first to confirm it actually notices.
  • We also found the previous split had left something undone. When the 1.x releases moved to their own page a fortnight ago, that page was never added to the list we give search engines — so it was never indexed. Fixed here, along with the reason it was possible to forget.
  • Nothing to do at your end. Your bookmarks and any links you have shared continue to work.

Version 2.52.1

August 1, 2026

Yesterday’s subtitle fix did not work — here is the real cause, and what we got wrong

  • Nothing you can see on the site changed today. This is the tool that lines subtitles up with the audio.
  • We said yesterday that Persian subtitles were fixed. They were not. Testing it properly this morning showed the same failure. We would rather correct that plainly than let it stand.
  • The real cause was two copies of the same piece of code, only one of which had ever been repaired. The version used for Persian, Arabic and Urdu still carried a fault that had been found and fixed in the other copy some time ago — along with a written note explaining exactly why it was wrong. The note travelled; the fix did not.
  • What it did wrong: it turned “the speaker might pause here” into “there is definitely a word boundary here”. When the recording had someone still speaking at that moment, the whole thing gave up.
  • Both copies now run the same single path, so they cannot drift apart again. That drift was the actual problem, more than either bug.
  • And we removed yesterday’s fix entirely. It was built on a misreading — a diagnostic report that shows the state after a failure was read as though it showed the state that caused it. Roughly two hundred lines went, including its tests, because code that repairs a situation that never happens is worse than no code: it looks like it is protecting you.
  • Nothing to do at your end. Subtitles already cover the full length of a recording — that part of yesterday’s work was correct and is unaffected.

Version 2.52.0

August 1, 2026

Turning a talk into an article had been failing, and the reason was a single word that two parts of the system spelled differently

  • Nothing you can see on the site changed today. These are the tools our team uses to turn a recorded talk into a transcript, subtitles and a written article.
  • Turning a transcript into an article had stopped working entirely. Two parts of our system have to agree on which writing engine to use, and a while ago we renamed that engine — in one of them. The other was never told. So every attempt was politely refused by a part of the system that genuinely did not recognise the name it was being given.
  • What made it hard to spot is that the refusal never reached the screen. The message explaining the problem was clear and correct, and our own page threw it away before anyone could read it — showing a meaningless technical line instead. The answer had been sitting there the whole time. Both halves are fixed: the two parts agree again, and when something does go wrong the actual reason is now shown.
  • Subtitles were also covering only the first twenty seconds of a video. When the tool that lines words up with the audio could not do its job, the backup simply handed out five-second slots in order — so an eighty-second talk got four subtitles and then silence. It now spreads them across the whole recording, and longer sentences get longer slots.
  • The backup was also quietly reporting the wrong length for the recording, because it measured the video by its own invented subtitles rather than the audio. A guess was being passed on as a fact, which is worse than the guess.
  • Most usefully, the system now says when it has fallen back. Before, a job where everything worked and a job where a key step failed looked identical from the outside — both reported success. That is precisely why this went unnoticed for so long.
  • One part of this is not finished, and we would rather say so. The underlying word-timing tool still fails on Persian audio, and we have not fixed that yet — it needs the specific recording to reproduce properly, and guessing at it has caused problems before. Subtitles will be reasonable but not precisely timed until then.
  • Nothing to do at your end.

Version 2.51.1

July 31, 2026

Routine maintenance on the outside components we build on — and a safety check we had been relying on without ever testing

  • Nothing you can see on the site changed today. This is housekeeping.
  • We keep the third-party building blocks the site is made from up to date, and two had newer versions available. Both are now current. One was only ever used by our own development tooling and never formed part of the live site at all; the other did, but the specific weakness it fixed could not affect us, because of how narrowly we had already configured it. We updated both regardless — the cost is nothing, and leaving routine notices unattended is how a notice that does matter gets lost in the noise.
  • The genuinely useful part came out of writing that up. When we bring in an article from elsewhere, we strip anything unsafe out of it and keep only a short list of things we allow. We had tests covering that list carefully — but nothing testing the layer underneath it, which is what blocks a link from carrying something harmful. We had been trusting it without ever checking it.
  • That is now tested, and we proved the tests work by deliberately breaking the protection first and confirming they failed. A test you have never seen fail is not evidence of anything.
  • Our writing tools also got noticeably faster. The development environment had been quietly running short of working memory and restarting itself mid-session — not failing, just silently starting over, which is why it went unnoticed for a while. It has been given proper room to work.
  • Nothing to do at your end.

Version 2.51.0

July 31, 2026

Remaking a story’s video threw the old one away first — so if the new one failed, you were left with neither

  • Nothing you can see on the site changed today. This is about the tools our writers use to turn a story or a reflection into a short video.
  • Making a video again started by deleting the one you already had. It removed the existing video, and only then began building the replacement — which for an illustrated story can take up to half an hour. If anything went wrong in that half hour, there was nothing left: not the new video, which never finished, and not the old one, which had already been thrown away to make room for it.
  • The order is now the other way round. The new video is built and stored first, the story is pointed at it, and only then is the old one cleared away. At no point is there nothing to show. If something fails now, the worst case is a leftover file nobody is using — which is a tidying problem, not a lost afternoon.
  • The same tool for reflections never had this fault, and that is the uncomfortable part: the two tools looked like they did the same thing in the same order, and one of them quietly did not. Reading one and assuming the other is how this survived.
  • Both video tools now keep a record of what they are doing. Before, a video that failed halfway left no trace at all — if you had closed the tab, there was simply no answer to “did that work?” And a video being built looked identical to no video being built, so the natural thing to do was start a second one, on the same machine the first was still using.
  • We had this written down wrong, and we would rather say so. Our own notes recorded these two tools as losing finished videos when a tab was closed. Checking properly showed they never did — the video was being saved correctly all along. The note was written from a search that only looked at part of the code. The real fault was elsewhere, and in one case worse than the one we had recorded.
  • Nothing to do at your end.

Version 2.50.0

July 31, 2026

We said yesterday that four more picture tools had the same weakness. Here they are, fixed — and a fifth we had scored wrongly

  • Nothing you can see on the site changed today. This finishes yesterday’s work on the tools that draw pictures.
  • Yesterday’s note listed four tools still at risk. All four are done. Every one of them now keeps its connection alive while it works, instead of going silent and being cut off by something in the middle.
  • Checking again found a fifth we had marked as safe. It does send updates as it goes — but only once per picture, and a picture takes long enough that a slow one could still exceed the limit. “It sends updates” and “it keeps the connection alive” are not the same thing, and that is exactly why it passed the first check. It has a proper keepalive now.
  • The uncomfortable part: the tool for doing this correctly already existed. It was written for this exact problem, and five of the eight picture tools simply were not using it. Nothing made skipping it fail, so nothing did.
  • We also built the missing other half. The browser side of these conversations was being written out by hand each time — about twenty-five lines, slightly differently, in each place. There is now one shared piece of code, so there is one way to get it right rather than seven chances to get it wrong.
  • And it fixes a failure every hand-written version had missed. If a connection simply stops without ever delivering a result, that is a failure — but the old code treated it as a normal ending and carried on to its success path. Nothing was reported, the old picture stayed on screen, and it looked exactly like a tool that had run and decided to change nothing. It now says clearly what happened, including that the work may still be finishing.
  • Two small leaks closed while we were in there. In two places a keepalive timer could outlive the request it belonged to — harmless in effect, but it relied on something going wrong later to clean it up, which is not a thing to depend on.
  • Nothing to do at your end.

Version 2.49.0

July 31, 2026

A reported fault in redrawing one picture of a story — which turned out to be hiding a second, worse one

  • Nothing you can see on the site changed today. This is the tool our writers use to redraw a single picture in an illustrated story.
  • It was reported as failing with an unhelpful technical message. That message was not the fault — it was what the fault looked like after being mangled on the way to the screen. The tool asked for an explanation, got a page of something else entirely, could not read it, and reported its own confusion instead of the problem.
  • The real cause: redrawing one picture takes longer than anyone had assumed. Drawing all twelve pictures keeps the connection alive while it works. Redrawing just one did not — because a note in the code described it as “fast”. It is not: it re-sends every character’s reference pictures, works out what everyone is wearing, and then draws. Left silent too long, the connection is closed by something in the middle, and everything after that is guesswork.
  • Both halves of that are now fixed. Redrawing keeps the connection alive exactly as the full run does, and when something does go wrong the message says what actually happened — including the case where the work is still running and it was only the waiting that stopped.
  • Then, while looking into it, we found something worse that nobody had reported. The picture machine can only do one job at a time, so each job reserves it. That reservation was being taken before checking the request made sense. So a request with something missing was refused — while still holding the machine, for half an hour, doing nothing. Anyone else was told it was busy. It now checks first and reserves second.
  • We also found two places where somebody closing their browser could destroy work that had already been done. The code tried to send a progress update to a window that had gone, and the resulting error stopped everything — including work that had finished and was about to be saved. Someone walking away is a perfectly normal way for a long job to end, and it is now treated as one.
  • And we checked the rest rather than stopping at the one that was reported. Four more picture tools have the same weakness that caused this. They are listed in our notes with a command to re-check them, and are being fixed separately rather than quietly bundled in here. We would rather write down a known gap than let it be found by someone using the site again.
  • Nothing to do at your end.
← All releases