Why Saving an Item Dropped Us at the Parent Account After 500 Milliseconds

Once we chose a sub-account, the app was supposed to keep that choice as we moved through the work. Then we clicked an item inside that account and landed back at the parent account, as if we had never chosen anything.

There was no warning. Nothing crashed. The screen simply forgot where we were.

The feature itself was useful and ordinary. An account administrator could use a dropdown to choose a sub-account, then see the detail screen narrowed to that sub-account’s information instead of the larger parent account. It was the kind of choice a person expects a tool to remember for the next few minutes.

Where we put the choice

We put it in the page address. A query parameter is a small labeled bit of information at the end of a web address, such as ?div=42. It seemed like the right home. Reload the page and the same sub-account stays open. Save the address or send it to someone, and it opens to the same place. The page could read the choice again each time it opened.

For half a day, we felt smart about that. The choice survived a refresh, and it could be shared. Those are real benefits. A note kept only in a page’s short-term memory disappears when the page reloads, while a note written into the address comes back with the page.

What we missed was the cost. Every link that was supposed to keep someone inside the chosen sub-account also had to carry that piece of the address forward. One missing &div= was enough to wipe out the context. It was like writing a room number on a stack of papers, then forgetting to copy it onto the next sheet. The work still exists, but you no longer know which room it belongs to.

The same bug, twice

The first failure showed up in the header link for an item. We had chosen a sub-account and opened an item inside it, and the link took us to the parent account’s screen. The link knew the item number, but it had forgotten the selected sub-account.

We fixed that one link by adding the missing piece of the address. It was a one-line change. It did not solve the larger problem, because another path had the same gap. After saving an item, the page did a short reload to bring us back to the detail screen, and that reload also left out the selected sub-account. About 500 milliseconds after saving, the screen sent us back to the parent account’s root view.

The cost was a whole commit spent hunting for every place the app built an internal destination. It also cost the patience that disappears quickly when a person saves work, blinks, and finds the tool has lost its place. Neither bug announced itself with a helpful message. We found both by using the feature and asking, more than once, “Where did the selection go?”

The two failures looked different on the surface. One came from clicking a related item and the other came after saving. But they were the same mistake: a new destination had been built without carrying the choice that defined the current view.

One home for the addresses

Sometimes a link should leave the current view behind. If you choose a different part of the tool, keeping the old choice could be wrong. The trouble is making that decision separately in every link, button, and reload. Sooner or later, one of them gets missed.

We should have built one small helper that makes the addresses for this page, instead of pasting &div= into more places. It starts with the choices that should travel along, adds the new details for the next destination, and produces the finished address in one place. A link to an item asks for the item it needs, while the helper remembers the active sub-account. A link that begins something new can deliberately leave the old choice out.

That moves the important question to one visible spot: what belongs to this view, and what does not? It also means a new link does not depend on someone remembering a hidden rule from months ago.

We built that helper after fixing the same lost-choice problem twice, which is a mildly embarrassing order to do it in. The header link and the post-save reload were one bug found in two places, a missing &div= each time. The fix that held was the single helper that builds every destination address for that page and carries the active sub-account forward by default. If a tool keeps a user’s chosen view in its page addresses, find out whether one piece of code builds all of those addresses, or whether every link and reload has to remember the rule on its own.

dxdev LESSON · paste into your AI coding agent
LESSON: State kept in the URL is only as durable as every link that builds a new URL from it
SOURCE: dxdev.com/everyday-ai/choice-that-kept-disappearing
WHAT HAPPENED: A sub-account selection was stored as a query parameter (like ?div=42) so it would survive a page refresh and could be shared as a link. That worked until any code path built a new destination URL without also carrying the parameter forward. An item's header link dropped it and landed back on the parent account. Separately, the short reload after saving an item also dropped it, quietly sending the user back to the parent account's root view about half a second after they saved. Both were the same root cause found twice as two different bugs. The fix replaced ad hoc parameter-copying with one URL-building helper for the page that carries the active selection forward by default, so a new link does not depend on someone remembering to add it.
THE RULE: State kept in the URL is only as durable as every place in the code that constructs a new URL from it; centralizing URL construction in one shared helper is what stops any single link from silently dropping the context.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any page state stored in a query parameter with more than one place in the codebase building destination URLs by hand.
      2. Any post-action redirect or reload built as a brand new URL rather than the current URL with updated parameters merged in.
      3. Two or more bug fixes that each added the same missing parameter to a different link, which is a sign the real fix belongs in one shared URL builder instead of at each call site.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.