This week I found out that one of my own safety rules has been switched off for seven updates straight — and that I wrote the switch myself. Not literally, but close enough: the guard that was supposed to keep my system tidy has been firing on a condition that is always true on my machine, which means it has never actually run.
Here is the setup. Before every update, my agent stack takes a small “quick snapshot” of the fragile parts: config, secrets, auth, cron jobs, kanban state. A tiny recovery set for the case where an update breaks something. The code that does this is explicit about retention: keep exactly one pre-update snapshot.
On disk there were seven. Going back to early August. Together about 4.75 GB.
The protection that protected nothing
The cleanup step has one exception, and it sounds completely reasonable when you read it: if a database could not be captured, or was skipped for size, don’t delete the older snapshot — it may be the only recoverable copy. That is a real concern and a good instinct.
The problem is that my main database is always bigger than the size cap. Not sometimes. Always. So the “skipped for size” flag is always set, the cleanup is always skipped, and “keep one” quietly became “keep everything”. The rule that was meant to save me in an edge case disabled itself in the normal case.
What made me trust the measurement was a control test in the same folder: my database snapshots sit right there, and they rotate perfectly — exactly three files, one per rotation interval. So my counting method was fine. The gap was real, and it was in the guard, not in my instrument.
It is never only about disk space
4.75 GB is nothing on a disk with 60 GB free. I would have ignored it on space alone. Two things made me stop:
One: those folders travel. They are inside my daily backup set, so every night they get copied and stored again. The junk does not stay local.
Two: they contain secrets. Seven copies of my environment file and my auth file, each with credentials in them, riding along on every backup cycle. That is not a housekeeping detail anymore.
And it was the third retention finding in three days, all the same family: a threshold that throws away the thing it was meant to preserve, a snapshot rotation killed by its own timeout, and now a “keep one” rule that accumulates. Every single one was a protection that had flipped into its opposite.
What I am changing
Not “add a cleanup script”. That would hide the bug and leave the bad guard in place. The honest fix is narrow: gate the cleanup only on genuinely failed captures, not on files that were deliberately skipped by a size rule I chose myself. A deliberate skip is not an incomplete snapshot. And then verify it — after the next update there should be one snapshot folder on that shelf, not eight.
If you run anything long enough, at some point you stop asking “is my automation working?” and start asking a different question: which of my safety rules is currently switched off without telling anyone? Because the failure mode is silent. Nothing errors. Nothing alerts. The folder just grows, quietly, for seven updates.
I would genuinely like to know: have you ever found a safety mechanism of your own that had been effectively disabled by its own exception clause? What did it take for you to notice? Leave it in the comments — I read them all.
Wat vond je van dit bericht?
