---
title: "After Picking a Child Event, the Site Linking Screen Kept Offering the Parent's Leagues"
canonical: https://dxdev.com/blog/2026-02-27_wrong-sport-was-quietly-deciding-the-list/
datePublished: 2026-02-27
---
# The Wrong Sport Was Quietly Deciding the List

A user reported that the screen for linking sites was offering the wrong leagues after an admin chose a child event from a dropdown. Nothing crashed. No red warning appeared. The page simply made a quiet, confident suggestion that did not fit what the person had selected.

I could see why this was frustrating. The wrong list only appeared after a particular sequence of clicks. The parent account could be one sport, while the child event inside it could be another. If those two happened to match, everything looked normal. If they did not, the list was wrong.

The first thing in the code was a label called `sport`. The filter used it to decide which leagues belonged in the list. For years, that had been fine because the account in the web address and the account whose information the page was using were always the same. One label seemed like enough.

Then the new dropdown changed the situation. An admin could stay on the parent account but open a child event inside it. There were suddenly two answers to a simple question: whose sport are we talking about?

At first, the filter kept following the old label. It was not a wild guess. It was the label the page had always used, and it still correctly described the parent account. But it did not describe the child event that the person had just chosen. That first answer did not work in the new flow. It cost a user patience, and it cost me time because the mistake stayed hidden unless the parent and child were different sports.

This kind of problem has a technical name: a **global variable**. It is just a shared labeled note that a web page leaves where any part of the page can pick it up. Shared notes are convenient until two parts of the job need different facts. Then the label can be right for one job and wrong for another, at the same time.

In this case, the page was already receiving information from the server when it loaded. The server wrote a small bundle of details directly into the page for the browser to use. That included the old `sport` label, which always came from the parent account. The browser did exactly what it was told. The trouble was that the instruction no longer matched the situation on the screen.

I did not change the meaning of `sport` everywhere. That would have traded one quiet mistake for many others. Plenty of places still needed the parent account's sport, and changing the old label would have made those places unreliable too.

Instead, I added one new, plainly named bundle for the selected event. It carried three pieces of information: its username, its sport, and its team name. The linking screen now looks for the selected event's sport first. Only when that bundle is not there does it use the older parent-account label.

That is a very small change on paper. One new bundle. One place that reads it. But the important part was not the number of lines. The important part was that the two different jobs finally had two different labels.

I also left a comment beside the new information. It says, in effect, that whenever the page needs the sport of the selected event, it must use the new value, not the older `sport` label. That comment matters because the old label is still sitting there, close at hand, with a name that looks perfectly reasonable.

A future person reading the code could easily reach for `sport` and feel sure they had found the answer. Without the note, they could accidentally put the same problem back. With the note, the trap is named where the next change will happen.

There is a lesson here that has nothing to do with sports or web pages. A familiar word can hide a changed situation. “Current customer,” “today's price,” “active job,” or “main contact” may have meant one thing for years. Then a new option, a new location, or a new way of looking deeper into a record makes it mean two things.

The danger is not always a dramatic failure. Often the system keeps moving and gives someone the wrong choice. That is harder to spot than a broken screen because it can look believable. A landscaping business might show the schedule for the main property after someone has selected a smaller job site. A school office might pull the parent record when the task is really about one student. The label is not nonsense. It is simply answering the wrong question.

The two labels were never the problem in the abstract; the fix that shipped was three fields wide, a username, a sport, and a team name, sitting next to a comment that tells the next person which one to trust when a child event and its parent disagree. That comment is the only thing standing between this bug existing once and existing again under a different ticket number.