Three Fixes on April 21 and Each One Was Called Done Too Early

On April 21, two quick fixes landed on the same day, alongside a third problem, and all three looked fine from the outside. The three touched registration, schedule management, and the way page files were released. They did not share a cause. They only shared a talent for hiding in ordinary-looking work.

A paid member who showed up as pending

A PayPal IPN, which is simply PayPal’s little message saying a payment succeeded, was not always updating the registration record that received it. The money had arrived, but a member who had paid still appeared on the list as pending, as if somebody had left a form half-finished on the kitchen table. Nothing in the system flagged the mismatch.

That was easy to miss because the important part looked fine. The payment had gone through.

The problem had been sitting there for a while, and the repair had two jobs. First, future successful payments needed to correct the registration status on their own. Second, the older wrong records in production needed attention too. We added a cleanup tool with an admin screen, a confirmation step, and a dry-run option. A dry run is like laying out all the ingredients before turning on the stove. It shows what would change without changing it yet.

We do not think a fix counts if it only helps the next person through the door. The bad rows were real, and leaving them behind would have meant the system kept telling a false story about people who had already paid. A forward-only fix can make a dashboard look healthier while the old mess stays under the rug.

A delete that did nothing

The next issue taught a different lesson. Bulk deletion was not working when somebody started from the broadest account level. We first thought it was a permissions problem. That was the wrong drawer to open. It cost the first part of the investigation, looking for a lock that was not there.

The problem was simpler, once we found it. The delete request was being sent with an organization-level address, but the receiving part of the system only understood smaller addresses, such as a particular group or member. It was like trying to mail a letter to “the apartment building” when the mail slot only accepts apartment numbers. The request did not cause a spectacle. It just did nothing.

The correction was to walk down from the broad address to the smaller one before asking for the deletion. That sounds small, but it changed the question we needed to test. The user sees “delete does not work.” The better question is whether we handed this part of the system an address it can use. Those are not the same problem.

Rather than spend hours guessing through an old application, we had an AI assistant trace where that address was built, follow the route to the delete request, and check which address fields were accepted. We still had to decide what the evidence meant and check the model of the problem. The assistant did the reading and left a trail to the exact places that mattered. On a day with several unrelated problems, that is a useful division of labor.

Page files that could change mid-load

The third problem was about releasing updated page files. During a release, some pages were still pointing straight at the working copies of the files that control how a page looks and behaves. That meant an edit happening during the release could reach a customer who was already loading a page.

The safer fix changed more than the page logic. We made dated copies of those files and pointed the pages at the dated copies instead. Think of it as serving dinner from the dish on the table, not from the chopping board while someone is still cutting vegetables. The point was to make the release process itself less likely to recreate the problem.

Three fixes, each declared finished too early

We keep coming back to how different these three looked from the outside. One was a paid registration that looked unfinished. One was a delete button that did nothing. One was a page that could change under somebody’s feet. It would have been tempting to call the day one big system failure and reach for one big explanation. That would have been wrong.

What connected them was the habit of stopping at the first reassuring answer. Each one had been declared finished by a signal that looked fine. The payment fix was not done until both new payments and old records were covered, which is why the dry-run cleanup had to deal with the rows still saying the wrong thing in production. The delete fix was not done until the correct kind of address was passed along, since it was never a permissions failure. The release fix was not done until the release method itself stopped reopening the risk, and the dated copies mean an edit can no longer land on a customer mid-load.

When someone tells you a fix is done, ask whether it covers the existing bad records as well as new activity. Ask whether the failing request was checked for what it actually sent. And ask whether the release process was changed or only the page.

dxdev LESSON · paste into your AI coding agent
LESSON: A fix that only helps the next request still leaves the false story in every existing record
SOURCE: dxdev.com/everyday-ai/problem-under-the-paid-stamp
WHAT HAPPENED: A PayPal IPN payment-success message was not always updating the registration record it applied to, so paid customers' records still showed pending. The fix had two required parts: making future IPNs self-correct the registration status, and building an admin cleanup tool with a dry-run mode to find and correct the existing wrong records already in production, since a forward-only fix would have left old paid-but-pending records lying and telling a false story. Two unrelated same-day bugs, a bulk delete failing because it was passed an organization-level address that the receiving code only accepted at a narrower level (a group or member), and static asset files being edited live during a release instead of served from dated copies, reinforced the same discipline: don't stop at the first reassuring partial fix.
THE RULE: When a bug has corrupted existing records, a fix that only prevents new occurrences is incomplete. The existing wrong records need their own detection-and-correction pass, ideally with a dry-run step, before the fix counts as done.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any bug fix that corrects behavior going forward without a companion tool or query to detect and correct already-corrupted existing records.
  2. Any data-correction or cleanup tool for production records with no dry-run or preview mode before it commits changes.
  3. Any API or endpoint call passing an identifier at one level of granularity, such as organization, into code that only handles a narrower level, such as a group or member, with no explicit resolution step walking from broad to narrow.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.