What a crash may cost

Part 6 of 7 of ./blog.sh v1.4

The queue can now swap two scheduled posts that share a slug across two years — with their media and their edit history riding along, because those are keyed by year and slug exactly like the post file. That sentence is short; making it true was most of a release cycle. The interesting part is not the swap. It is what happens when the power goes out in the middle of one.

The budget is zero

A move is several renames, and a crash can land between any two of them. The rule 1.4 holds to: whatever the moment, a crash may cost you the move — never a post. Files step aside under parking names before anything writes; a failed write puts everything back, byte for byte; a hard kill that strands a parked file leaves it where check finds it and says truthfully what it is.

The advice is part of the system

That last piece turned out to be the hardest. An early version of check's advice said "this is a stale copy — delete it", from nothing more than a file existing at the parked file's old name. But parking only happens when two posts share a slug, so the file standing there is by construction a different post — and after the right crash, the parked file is the only copy of yours there is. The advice now rests on the parked post's own identity: proven-stale names where the live copy sits; unproven says plainly that this may be the only copy, compare before you touch it, and never delete.

A recovery instruction that can destroy what it recovers is a bug like any other. It just took an audit aimed at our own fixes to see it.

Comments