Five Commits Hid Behind One Closed Ticket and a 404

The ticket was marked closed. We ran the creation flow on l3 that afternoon and it failed on step one.

It was not a subtle failure. After creating a new event, the system redirected to an admin page that no longer existed. A hard 404. Any real user who went through that flow would have assumed the event didn’t save and tried again, or called support.

We reopened the ticket. By the end of the day it had produced five commits across five different files in five different layers of the stack.

the redirect was the door, not the bug

The post-save destination after creating an event was a hardcoded page reference. The page it pointed to had been reorganized at some point and nobody had followed the reference forward. One line to fix.

Fixing the redirect uncovered the edit flow.

When you create a new event in the platform and then try to edit it, the admin panel constructs a link back into the event form. That link was built with a pageId assumption that held for events attached to the original event structure. New-style events use a different type identifier. The edit link generated a URL that either loaded the wrong form or no form at all.

That made two broken things from one broken flow, in two different files. Neither fix implied the other.

image persistence had nothing to do with the redirect

While we were in the create flow, we noticed that images attached to new events were not surviving the save. The upload succeeded. The preview looked fine. After a page reload, the image was gone.

The image-binding step for events runs through a separate code path from the main form fields. It takes uploaded images and attaches them to the event record by ID. For new events, that step ran before the event record had a stable ID to bind to. The images saved against a temporary identifier and became orphans on reload.

This was a sequencing problem inside the create pipeline. It was invisible unless you uploaded an image and then checked whether it was still there after leaving and returning to the page.

We would not have found it if we had stopped after fixing the redirect.

custom event categories exposed an assumption about lists

The platform has a canonical list of event categories baked into several places in the admin stack. When you create an event for a recognized category, the lookup resolves cleanly. When you create one for a custom category that a customer added outside the canonical list, several parts of the flow that look fine on the surface fail.

The category-handling code in the event create path did a lookup against that canonical list and returned a default on miss. Silent substitution. The event would save, but with the wrong event category attached to it.

The form accepted the custom category. The saved record stored something else. For any customer running events in a category that was not on the original list, every new event was saved with the wrong category value.

The fix was changing the lookup to respect custom category entries from the database rather than falling back to the canonical default. Four lines. The wrong behavior had been there for a while.

dateText was a string that only looked like a date

Events have a display date field separate from the actual scheduled date. The display field is called dateText and it is freeform. Customers put things like “Saturday, June 7” or “June 7-8” or “TBD.” It is not a parsed date. It is a string.

The form handled this correctly on the way in. The save path, though, passed it through a date-formatting utility that assumed it was a real date. For any dateText value that did not parse, the utility returned an empty string and overwrote the field.

Customers who entered “June 7-8” saw that value disappear on save. No error message. Just gone, replaced by nothing.

This one lived in the date-handling utility layer, which is shared across multiple parts of the admin. A different file from any of the others.

the hotfix we were sure of, and why we ran l3 anyway

By the time we had fixes for the redirect, the edit link, the image persistence, the custom event category handling, and the dateText field, we had touched five files across the create pipeline and the admin display layer. Each fix looked correct in isolation. Each had passed a local check.

We had already been wrong once on this ticket. The first hotfix went out the day before, on a diagnosis we were sure of. Cart-created events under an organization parent were receiving the placeholder value org as their event category, and that broke the photo path and the sub-login. We wrote a driver page that ran three cases against the parent, all three passed on l3, and we shipped it.

The next morning a tester hit the same symptoms on a fresh event. The category value really was wrong, but it was one column of several that the cart’s inline inserts wrote differently from the standard account setup. Our driver only checked the column we already believed in, so it could not fail on anything else.

So this time we ran the full creation flow on l3 with a test payment, because the ticket touched code that runs adjacent to cart registration for paid events. A change in the event create pipeline can produce a checkout flow that looks fine until someone tries to pay for something. The only way to confirm that path is clean is to run it.

The cart path was fine. Finding that out on l3 cost five minutes. Finding out from a customer with a failed registration would have cost a day.

That same afternoon, we fixed a stats-page outage that was down across 314 sites. One cause: DataTable hitting an ADO cursor on aggregate queries, producing a result set it could not handle. One fix, one commit. The contrast is useful. One-cause bugs announce themselves clearly. The multi-cause ones look the same from the outside.

what the five failures had in common

The canonical event category list was a reasonable design when the platform launched and the list was short. The date formatting step was reasonable when dateText was always a real calendar date. The image-binding step ran after save in the original flow because in the original flow there was no timing problem.

None of these were bugs when they were written. They became bugs when the system around them changed and nobody went back to check every place the old assumption still lived.

A ticket that says “new events are broken” is pointing at a feature area that has not been walked end to end in a while. The symptom is the entry point. Behind it is a map of every assumption that was never updated when something adjacent changed.

We found all five by walking the flow the way a user would, watching what happened at each step, and following each new failure forward instead of running a targeted test against the specific symptom.

Five files, five layers, one flow that hadn’t been walked in years: the redirect, the edit link, the image binding, the category lookup, dateText. Each one shipped clean the day it was written and broke the day something next to it changed. When a ticket describes a feature as broken, run that feature end to end before you trust a check that covers only the diagnosed cause. A closed ticket can still hide failures behind the first one.

dxdev LESSON · paste into your AI coding agent
LESSON: 'New events are broken' means walk the whole flow, not patch the first symptom you hit
SOURCE: dxdev.com/blog/not-one-tournament-bug-five
WHAT HAPPENED: A ticket marked closed still failed on step one when the creation flow was actually run end to end, redirecting to a page that no longer existed. Fixing that stale hardcoded redirect uncovered four more independent bugs hiding behind it in the same flow: an edit link built with a pageId assumption that broke for the new event type, uploaded images silently orphaned because the binding step ran before the record had a stable ID, a canonical category list silently substituting a default category for any customer-added custom category, and a date-formatting utility that blanked any freeform display-date text it couldn't parse as a real calendar date. None of the five were related to each other; each was found only by continuing to walk the full flow after fixing the previous one. A prior same-ticket hotfix had also failed in production despite passing a driver script, because that driver only checked the one column we already suspected was wrong.
THE RULE: When a bug report says a whole flow is broken, treat the reported symptom as the entry point, not the whole problem. Walk the complete flow end to end the way a real user would, because unrelated bugs often hide behind each other in a flow nobody has run start to finish in a while, and a fix verified only against the specific symptom you expected can still miss the actual cause.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any bug fix for a flow-is-broken ticket that stopped after fixing the first symptom found, without walking the rest of the flow end to end as a real user would.
  2. Any verification or driver script written to confirm a fix that only checks the specific field or column the author already suspected, rather than the full set of fields the flow touches.
  3. Any code path, such as list lookups, date formatting, or ID-dependent operations, carrying an assumption that held when it was written but was never re-verified after an adjacent feature, such as custom entries, freeform fields, or async record creation, was added.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.