Line 10 and Line 2160 of the Same File

The Save Button That Was Only Pretending

On April 28, we were tracing reports about comments that would not stay saved. Someone would write a note on an account, press Save, and see the page behave as if everything had worked. Then they would reload the page. The note was gone.

The person using the page had already done their part. They typed the words. They pressed the button. The page gave them a reassuring answer. Then the work disappeared anyway.

We looked in the wrong place first. A comment that vanishes after a reload sounds like a refresh problem. Maybe an old copy of the page was hanging around. Maybe the person had missed the button. Maybe the comment was there and the screen was not showing it. Those were reasonable things to check, and none of them explained it. Each check of the stored record showed the same thing: it had not changed.

There was no dramatic crash that made everyone stop. The cost was quieter and more wearing. Customers and staff could spend time entering comments, changing an email address, setting a flag, changing a password, or deleting a record. The page thanked them for it. Nothing stuck. It also cost us time, because the first explanations sounded so ordinary that they pulled our attention toward the screen instead of the actual change underneath it.

The cause was a setting called a dry run. That sounds technical, but it means a practice pass. Think of laying out ingredients, measuring everything, and even reading the recipe aloud, but never putting the cake in the oven. The system went through almost all the motions of an edit. It built the instruction. It returned the usual success message. It skipped the one step that makes the change real.

One line near the top of a file had been set to false. With that setting false, the account page could handle around 60 different requests, most of them changes, without saving any of them. Comments were only the first thing people noticed. The same setting affected changing an email address, changing a password, flagging an account, and deleting a record.

The setting had been put there for a sensible reason. Back in October 2023, someone was working on a change locally and did not want to make real changes while testing the surrounding work. In the same session, two temporary safeguards went in. One made errors easier to see. The other prevented real edits. Both are understandable ways to work carefully while trying something out.

Then the work was parked for about two and a half years.

When it was picked up again, there was a cleanup before the merge on April 24, 2026. The first temporary safeguard was found and removed. The second was missed. Nobody ignored the idea of cleanup. The cleanup note even said that old debugging material from October 2023 was being restored. But the two temporary changes lived far apart in a very long file. One was near line 10. The other was around line 2160.

That distance matters more than it sounds. If you put two sticky notes on opposite ends of a 2,000 page book, you may remember taking one out and still forget the other exists. Two and a half years is long enough for a clear memory of what was temporary to turn into a blank spot.

The branch was merged on April 24. The release on April 28 sent the missed setting into production. A fix went out at 22:03 that same night. The repair itself was tiny. False became true.

Why nobody got an error

The hard part was the silence. The page was designed to say success when the process reached its normal end, and here the normal end did not include saving anything. There was no error message, no obvious warning, and no loud signal that a person had done work for nothing. The first dependable signal came from a customer who noticed a comment had vanished.

A button is not proof that something happened. A cheerful message is not proof either. The proof is the result you can see afterward.

That applies far beyond software. If a bookkeeper says an invoice was sent, check that it reached the customer. If a new employee is told their access is ready, have them sign in. If you set up an automatic payment, look for the first payment to clear.

Temporary workarounds have the same problem. They are easy to remember while they are fresh and much harder to see after a busy week, let alone after years. When we make a temporary change now, we want it written down with its companions. Not just “remember to undo this,” but a short list of every switch changed for that piece of work. A list still knows what happened after the person who made it has moved on to something else.

dxdev LESSON · paste into your AI coding agent
LESSON: A success message only proves the code reached its end, not that the write it promised actually happened
SOURCE: dxdev.com/everyday-ai/save-button-that-was-only-pretending
WHAT HAPPENED: Two temporary safeguards were added in the same working session about two and a half years earlier: one made errors easier to see, the other made every account edit on a page a practice run that never actually wrote anything. A cleanup on merge found and removed the first, near the top of the file, and missed the second, roughly 2,150 lines further down. For four days, around 60 different account actions, including saved comments, email changes, password changes, and deletes, returned the page's normal success response while silently changing nothing, because the page's normal exit path was reached whether or not the write itself happened. The first real signal was a customer noticing a comment had vanished after a reload.
THE RULE: A success message proves the code reached its normal exit path, not that the effect it promised actually took hold; the only real proof is reading the changed state back from a fresh read afterward.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any write path (save, update, delete) whose definition of success is reaching the end of a function rather than a verified state change read back afterward.
      2. Any dry-run, debug, or test-mode flag with no companion list of every other temporary flag changed in the same working session, so a later cleanup can find one and miss another far away in the same file.
      3. Any temporary safeguard whose removal was verified by reading a changelog or comment rather than by testing that a real write actually occurs.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.