What one project can hold, and what happens at the wall
Three ways the work could be lost, measured rather than guessed at. The expensive one is the failure that never recovers: a project past the size a store will take fails every autosave from the moment it crosses the line, and a reload does not clear it.
Roughly thirteen thousand keyframes
A project is one document, and the store holds one mebibyte in a document. That is the wall, and until now nothing in the editor knew where it was.
It sits at about thirteen thousand keyframes however they are spread — ten layers with two hundred and fifty keys on each track, or a hundred layers with twenty-six — which a dense six-second piece reaches without trying to.
The size is measured before the save now and refused with a sentence rather than an error, and it is handed back on every save that works. So the editor can say something at four fifths full, while there is still room to change your mind and deleting work is avoidable.
One unreadable project hid the rest of the list
The project library reads every project it is about to list and checks each one against what the running build understands. It did that in a single pass over the lot, so one project the build could not read took the whole list with it — ninety-seven readable ones included.
It reads them one at a time now and leaves out only what it cannot read, naming it in the log where it is useful. The local half of the store had always done this. The half in production was the half without the guard, which is the usual way round for something nobody has had to test.
The draft went down after the save, not before
A copy of the work is kept in the browser so that a save which fails is not work that is gone. It was being written after a save succeeded — the one case where it is least needed — and never in the case it exists for.
It goes down before the request now, against the last revision that landed. A save that never comes back is no longer a tab nobody may close.
Why not simply make it bigger
The limit is the store's rather than a policy: a document holds a mebibyte and a project is a document. Splitting one project across several documents is a real answer and a large piece of work — it changes what a save is, what a revision is, and what should happen when half of one arrives.
Until that is worth doing, the honest thing is to say where the wall is, in a sentence, before somebody walks into it.
Questions
- How big can a project get?
- One mebibyte, which is roughly thirteen thousand keyframes however they are spread across layers. The editor warns at four fifths of that and refuses the save past it.
- What happens if a project is too big to save?
- The save is refused with a message naming the size, and the work stays in the tab. Removing layers or keyframes brings it back under the line and saving resumes.