Finding out what was quietly filling the memory

This project keeps its entire memory in a single record with a hard size limit, and it has been able to tell you for a long time how many days remain before that record is full. What it could never tell you was WHY. The number counted down and named no cause, which makes it a deadline nobody can act on. The reason turned out to be built into the measuring tool. Most of the collections the project keeps are given a size budget, and the tool that measures what is taking up room walks that list of budgets. Anything without a budget is invisible to it — and thirty-five of the fifty collections have no budget at all, including the ones that hold who you are, your session, and your vault. The arithmetic had been sitting in plain view. The hourly background task only ever writes to collections that DO have budgets, and a collection at its budget throws away an old entry every time it adds a new one — so it stays the same size and adds nothing to the total. Yet the record grows by about three hundred bytes every hour, and the background task runs once an hour. The growth was entirely in the half the tool could not see. The project's own status page had even been reporting this every single time it was asked, in a line that says bytes exist in the record that belong to no measured category. Nobody could do anything with it, because doing something required exactly the breakdown that did not exist. So the breakdown now exists. The status page lists the heaviest collections, largest first, and marks each one with whether it has a size budget or not — because two collections of the same size have completely different futures. One will stop growing on its own. The other will not. Three things about how it was built are worth saying. It is a separate measurement rather than a widening of the existing one, because the existing one feeds several other calculations and quietly changing what it counts would have changed all of them. It is worked out fresh each time it is asked for and never written down, because storing a thirty-five-item breakdown inside the very record you are trying to keep small is a measuring tool that causes the problem it measures. And the safeguards around it were deliberately broken eight ways to check each one complains; six did, and the two that did not were examined and found to be genuinely interchangeable with the original — the same behaviour written differently — rather than gaps. Writing a test to \"cover\" those would have been writing a test that can never fail, which is a thing this project has learned to recognise and refuse. One thing this makes concrete rather than theoretical: joining this project writes into four collections that have no size budget and never discard anything. A handful of people is nothing. Growing beyond that has no gentle path, and that is now a number anyone can read rather than something you would have to go into the source to work out.