---
title: "After the Recovery Finished, the Page That Ran It Was Still Live"
canonical: https://dxdev.com/blog/2026-01-27_league-was-back-but-i-wasn-t/
datePublished: 2026-01-27
---
The league was back. All **327 teams** had returned. I should have been able to close the page, go home, and call the recovery finished.

Instead, I looked at the two lines near the top of the file and realized I had left the page loaded like a nail gun on a workbench.

I call it a **recovery script**, which is just a page that puts lost information back where it belongs. In this case, a customer's whole sports site had been deleted. The job was to bring back one league without rolling back everybody else's work. The page copied the league's saved information from an older backup, piece by piece, then connected the pieces back together.

The first thing I tried was the obvious thing: bring the site back. That worked. The league came back. But treating that successful run as the end of the job did not work. The page was still sitting at an internal address with a real customer account named in it. It was also set to its writing mode.

That second detail is worth saying plainly. The page had two settings. **Plan** meant, “Show me what you would do.” It counted the rows of information, listed the teams, and wrote down a plan without changing anything. **Run** meant, “Go ahead and change the records.” The plan was a rehearsal. The run was the actual work.

When I finished restoring the league, the page was still set to run. A bookmark, a mistyped address, or someone checking whether the page opened could have started the same writing job again against the same real account. There was no extra button asking, “Are you sure?” The page would have treated an ordinary visit as permission.

No customer data was hit a second time. I caught it first. Still, that is not the same as saying there was no cost. The recovery was no longer something I could safely forget about. Until I fixed those two lines, one accidental visit could have turned a careful restoration into a second full pass over a real customer's records. The work that had seemed finished still needed an end of day cleanup step.

The uncomfortable part was how ordinary the trigger was. The danger was not another planned recovery. It was a web page responding to a visit. A bookmark, a mistyped address, or someone checking whether the page opened could have started it. The first run needed deliberate attention. The next one could have started through the same small act people take all day: opening a link. That gap between “I mean to do this” and “I happened to visit this” is where risky tools need to protect people.

The fix was only three lines. I replaced the real account name with `USERNAME_GOES_HERE`, which cannot point to a real account. Then I changed the setting back to plan and left a comment saying that changing it to run was for a live job.

That did two useful things. First, if the page opened by accident, it had nothing real to aim at. Second, even if someone wanted to use it for a real recovery later, they had to make two separate choices: type a real account name and switch from plan to run. One forgotten setting would not be enough.

I also made sure the page had one master switch. Its “may I write?” decision came from the plan or run setting, instead of from another separate yes or no box buried lower in the file. That matters because two switches can disagree. A page can look safe at the top while a forgotten setting elsewhere still lets it make changes. One switch is easier to see, easier to test, and harder to leave in the wrong position.

This is not only a lesson about old software or deleted websites. Plenty of ordinary work has a version of this problem. A payroll sheet may still point to last month's list. A mass email tool may have real addresses loaded after the test is over. A piece of equipment may be left ready for the next person who walks up to it.

The fix took three lines, not a redesign: a placeholder where the real account name had been, the setting flipped back to plan, and one write switch instead of two that could disagree with each other. That's the whole test worth running on anything left plugged in when a job looks finished: is it aimed at nothing, and does starting it again for real require two separate deliberate mistakes instead of one ordinary visit?