Neither half of the change was wrong. The interaction between them was — and that is the kind of defect a test suite rarely catches.
Re-importing a repository destroyed the snapshot it was replacing. Nothing was permanently lost, and that was luck rather than design. Here is what happened.
Importing a repository ran in stages: copy the files, split them into chunks, embed the chunks, then mark the snapshot complete. Completing it originally just set a status, so completing before checking that embedding had succeeded was harmless.
Later, completing a snapshot also began promoting it — making it the one the analyzer uses, and retiring its predecessors along with their embeddings. That was correct on its own: without it, every re-import left the previous copy behind for good.
Put together, a re-import whose embedding step failed — an expired AI key is enough — would promote an empty snapshot over a working one and reclaim the working one's chunks. The project was left with nothing the analyzer could use, from a routine retry that looked like it had simply failed.
It fired during testing: two snapshots retired, 170 chunks purged. It survived because a snapshot is a derived copy of a repository we do not host, so re-importing rebuilds it — and because no stored analysis happened to reference either one.
Embedding is now confirmed before completion, and a test holds that ordering in place. But the useful lesson is not "check before you complete". It is that a method became destructive without its callers being re-read, and the ordering that made that dangerous was already sitting in the file, harmless, waiting.
When you change what an operation means, the risk is not in the change. It is in every place that called it back when it meant something else.
Corporate AI 365 works like a forward deployed engineer on every project — it learns your codebase, diagnoses what your staff report, and carries the fix through your approval gates to release.
Try it on your own code More posts