--- title: "1,477 Lines of Recovery Code Replaced Three Scripts That Disagreed" canonical: https://dxdev.com/everyday-ai/three-old-copies-nobody-meant-to-compare/ datePublished: 2026-01-29 --- Hundreds of account records had disappeared from a customer's organization, and the first thing we opened was a folder with three old recovery scripts in it. Each script was written for a different category, and each was meant to put a customer's organization back together from an older copy of the data. At a glance they looked like three sensible tools for three different jobs. They were actually three versions of the same old idea, each changed a little over the years. Opening that folder cost us time. We had to stop and read three long files carefully before changing a line. The scripts were similar enough that we couldn't assume a fix in one belonged in the others, and different enough that we couldn't safely treat them as identical. Then we found what they had in common. ## Where the numbers collided When an organization is rebuilt, its records get copied into a shared system that holds many customers' data. Each record has a number attached so the system knows what belongs with what. The technical name for one of those labels is a **primary key**. It's just a number that says "this is this particular record," and not some other record with a similar name. Those numbers can't simply be copied over, because the old ones may already be in use. So the recovery process gave related records temporary placeholder numbers, copied everything across, and then replaced each placeholder with the new real number. That last replacement was where the old scripts went wrong. Imagine three families putting labels on boxes in the same storage room. One family has a box marked 42. Another family also has a box marked 42. If you tell someone to replace every 42 with a new label, without saying whose boxes they are touching, they can change the wrong family's box. That is what the scripts could do. They updated records with a matching old number, but never limited the change to the customer whose organization was being restored. A small test with one account could look fine. A larger organization, where many accounts had been created around the same time and old numbers overlapped, could reconnect one account's records to the wrong records. ## Patching three copies, or building one The obvious move was to patch the first script, then the second, then the third. Fixing three copies would have meant trusting that we had found every copy, every slightly changed version of the same mistake, and every future copy someone might make. So the three scripts became one [recovery engine, 1,477 lines long](/blog/copy-first-remap-ids-second-site-recovery-engine/). That is not a smaller file, and by the usual measure of fewer lines it isn't a tidy win. But the differences between categories moved into a set of instructions. The engine looks at the backup, works out the category, and uses the right list of tables and fields without becoming a separate copy of itself. The repair now has one home. Every time the process swaps an old number for a new one, it also checks which customer owns the record. The recovery can no longer treat every matching old number in the whole shared system as if it belonged to the same organization. ## One engine, one check Having one engine made another piece of work possible. The engine has hand-written lists of the information it needs to copy. Those lists can fall behind when a new feature adds a new field, and a missing one can mean leaving part of a customer's data behind during a recovery. With one engine, we could [build one check](/everyday-ai/list-i-could-not-trust/) for it. The check reads the lists in the recovery file, compares them with a spreadsheet-style export of the live database, and points out what is missing. It has thousands of columns across hundreds of tables to compare. That would have been much harder with three drifting versions of the recovery process, each with its own list and its own history. Plenty of ordinary work grows this way. Someone makes a good checklist for closing a job. Another person copies it for a different customer. A third copy gets an extra step. Months later, an important safety check is added to one copy but not the others. What looked like flexibility turns into a hunt through three almost-matching pieces of paper when something goes wrong. The slow drift is the dangerous part. Each copy gathers its own small changes until the differences look intentional, even when nobody can explain them. By the time you need to fix a shared mistake, you first have to figure out where it still lives. The three old scripts never checked which customer owned a record before replacing a placeholder, which is how a customer's accounts could vanish. If you have near-identical copies of a critical process, a safety check added to one of them may be missing from the rest.