Why the Undo Restored the Old Value Instead of a Fresh One

One routine step did three things in a required order, and when the last one failed, it left the account half fixed and hid the damage from the check built to find broken accounts.

The step restored one setting, then restored another, then ran a final action that finished the job. If that last action failed, the code reported the failure and stopped. By then the first two changes had already gone through. Some settings looked updated as if everything had worked, and the piece that mattered was still missing.

The setting that kept the watch list

One of the settings changed early was the exact thing a separate, regular check used to find broken accounts. So a partial failure left a mess and also took the account off the list of things anyone was watching. The bug broke the account and erased the one signal that would have told anyone it was broken.

Why reordering was off the table

The obvious instinct is to move the risky step first, before anything else changes. That didn’t work here, because the steps depended on each other in that order. One setting had to be in place before the final action would target the right record. The same setting was also what made the record findable to the routine check afterward. Swapping the order would have traded a recoverable failure for a different, worse mistake.

What shipped: a plain undo

We didn’t build a fancier retry or a bigger safety net. Before making any change, the code now records exactly what the account’s settings were beforehand. If the final action fails, it puts those settings back as they were, and it does not reset them to a fresh default that would look like nothing had happened recently.

That distinction mattered. A fresh-looking value would have reset the clock on how long the account had been in trouble, making an old problem look brand new. Restoring the real original value kept the account visible to the same routine check that already knew how to find and fix it. We built no new detection process. The one that already existed just needed the truth handed back to it.

One more small thing went in alongside it. If the undo itself fails, that gets said plainly instead of swallowed. A partial fix that fails silently a second time is the same problem again, one layer deeper.

What to check in your own business

Any multi-step process that can fail partway has the same choice hiding in it. A form submission, a multi-part refund and an onboarding checklist all qualify. When something breaks halfway through, does the failure leave a state your existing checks can still recognize as broken, or does it quietly erase the signal that was supposed to bring a person back to fix it?

Look at what your process leaves behind when it stops midway. The rollback here restored the account’s own original setting because that original value was what the existing check read to decide what counted as broken.

dxdev LESSON · paste into your AI coding agent
LESSON: A rollback should restore what was there, not what looks fresh
SOURCE: dxdev.com/everyday-ai/partial-fix-erased-its-own-warning-sign
WHAT HAPPENED: A function performed several writes in a required order with no transaction wrapping them. When the final, riskiest write failed, the earlier writes stayed committed, leaving the record in a broken, half-updated state. One of those earlier writes was also the exact value a separate reconciliation routine used to find broken records, so the partial failure silently removed the record from that routine's results. The fix captured original values before writing and restored them precisely, not a fresh default, on failure, so the record fell back into the exact shape the existing routine already knew how to detect and repair.
THE RULE: When a multi-step operation can fail partway and its steps cannot be reordered or wrapped in one transaction, the fix is compensating undo that restores the original values, not new ones, specifically so any existing detection or retry mechanism that reads those values still recognizes the record as broken.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any multi-step write sequence with no transaction wrapper where an earlier step's success is committed independently of whether a later, dependent step succeeds.
  2. Any such sequence where one of the earlier writes is also a field a separate monitoring, reconciliation, or retry query filters on, meaning a partial failure could remove the record from that query's results.
  3. Any rollback or undo logic that restores a cleared or reset value using a fresh timestamp or default rather than the record's actual prior value.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.