Four Lines That Sent Someone to a Dead End

A bad bracket ID sent someone straight to the generic internal-error screen instead of a plain “we cannot find that,” because the code’s own escape route for bad IDs broke the exact same way the original request already had.

The page was part of a sports product. A person followed or typed a link with the wrong ID, and the page did not simply say, “We cannot find that.” It showed the generic apology screen that appears when something breaks behind the scenes. From the person’s side, it is the difference between a locked door with a sign on it and a door that suddenly falls off its hinges.

The strange part was that the missing bracket was not the thing breaking. The code already had a plan for a bad ID. It was supposed to send the person back to a safe landing page. That plan was the first thing tried, and it did not work. In fact, the attempt to gently send someone away was what caused the error screen.

The cost was not a bill or a lost database. It was someone’s patience. They had asked for a bracket and got a dead end with no useful explanation. It also turned a small guardrail into a same-morning hotfix, because a basic bad-link case was reaching the broadest error page in the product.

The technical name for the first approach was Response.Redirect. It sounds dramatic, but it is just a note sent to the browser that says, “Please go fetch this other page.” That note has to be sent before the page has started talking back. Think of it like changing the delivery address on a package before the truck leaves. Once the truck is down the road, the instruction is too late.

This instruction was being sent deep into the page’s work, after it may already have started sending its response. Worse, the new address was assembled from bits of the same bad request. If the bracket ID or page information was missing or messy, the escape route was built from that mess. So the first fix had two weak spots. It tried to change direction too late, and it tried to build the new direction from the broken situation.

The repair was four lines of actual code. The old hand-built address and the two browser redirects were removed. In their place, the page used a small existing helper that handed the request directly to a known page inside the product. The browser was not asked to make a second trip. The address in the browser did not change. The person simply received the safe page’s output in the same visit.

That is called a server transfer. It means the handoff happens inside the building instead of sending the visitor back out the front door with a new address. In this particular spot, that mattered because it did not depend on sending a late note to the browser. The bad-ID path stopped producing the internal-error screen.

There is an ordinary business lesson in that tiny change. A backup plan can fail for the same reason the original plan failed: it is still depending on the part of the situation that is already unreliable. If a customer calls with a wrong account number, the answer should not depend on successfully reading the wrong account number again. A fallback needs solid ground beneath it.

I also do not want to make this sound neater than it was. The safe page used for the handoff had problems of its own. The hotfix stopped the immediate failure. It did not clean up every rough edge in the place where people now landed. The code kept a comment saying that work was still pending, even with a typo in the word. I think that was the right call.

It is tempting to erase a note like that before a change goes out. It can make the work look unfinished, because it is unfinished. But removing the note would not make the remaining problem disappear. It would only hide it from the next person who opens the file, perhaps months later, and assumes the fallback page was carefully chosen and fully healthy.

There is a difference between a problem you have solved and a problem you have made smaller. Both are valuable. Confusing them is how a temporary detour becomes the permanent road nobody remembers building.

Four lines was enough because the fix stopped asking the failure to save itself: swap a hand-built redirect assembled from the bad request for a transfer to a page that needs nothing from it. That’s the actual test for any backup plan: does reaching it depend on the same broken input working correctly one more time?

dxdev LESSON · paste into your AI coding agent
LESSON: A fallback built from the same broken input that caused the failure can fail the exact same way
SOURCE: dxdev.com/blog/2026-02-19_four-lines-that-sent-someone-to-a
WHAT HAPPENED: A page had a plan for a bad bracket id: send the visitor to a safe landing page via a browser redirect. That redirect's target URL was built from pieces of the same request that was already bad, and the redirect call happened deep enough in the page's execution that the response may have already begun sending. Both weaknesses meant the fallback path itself threw an error, so a person who simply mistyped or followed a stale link got the generic internal-error screen instead of a plain not-found message. The four-line fix replaced the hand-built redirect with a server-side transfer to a known-good page, which does not depend on sending a browser instruction from a response that may already be underway.
THE RULE: A fallback path must not depend on the same unreliable input, or the same assumption about response state, that caused the original failure; if it does, the fallback is just a second copy of the bug.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any redirect call issued after the response may have already started sending output to the client.
  2. Any fallback or error-recovery URL assembled from the same request data that is already known or suspected to be malformed.
  3. Any error-handling branch (bad id, missing record, invalid input) that has no test exercising it with genuinely bad input, so its own failure mode has never been observed.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.