---
title: "Four Lines That Replaced Response.Redirect on the Bad-ID Page"
canonical: https://dxdev.com/everyday-ai/four-lines-that-sent-someone-to-a/
datePublished: 2026-02-19
---
A link with a wrong ID in it dropped the visitor on the generic internal-error screen instead of a plain "we cannot find that." The code's own escape route for bad IDs broke the same way the original request had.

The page was part of a client-facing web platform. A person followed or typed a link with the wrong ID, and instead of a simple "we cannot find that," they got the apology screen that appears when something breaks behind the scenes. From their side, it is the difference between a locked door with a sign on it and a door that suddenly falls off its hinges.

The missing record was not what broke. The code already had a plan for a bad ID: send the person back to a safe landing page. That plan was the first thing tried, and it failed. The attempt to gently send someone away is what produced the error screen.

The cost was not a bill or a lost database. It was someone's patience. They had asked for a record 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.

## Why the escape route failed

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 go out 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.

Ours 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 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 built the new direction out of the broken situation.

## The four-line repair

The repair was four lines of actual code. We removed the old hand-built address and the two browser redirects. 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, and the address in the browser did not change. The person received the safe page's output in the same visit.

That is called a [server transfer](/blog/response-redirect-vs-server-transfer-yellow-box/). The handoff happens inside the building instead of sending the visitor back out the front door with a new address. Here that mattered because it no longer depended on a late note to the browser or on anything built from the bad request. The bad-ID path stopped producing the internal-error screen.

A backup plan can fail for the same reason the original plan failed, because it still leans 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.

## What we left unfinished

We 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, but it did not clean up every rough edge in the place where people now landed. We kept a comment in the code saying that work was still pending, typo in the word and all. We think that was the right call.

It is tempting to erase a note like that before a change goes out, because it makes the work look unfinished, and 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, who would then assume 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.

When you review any backup plan or error path, check whether reaching it depends on the same broken input working correctly one more time. And leave the note about remaining work where the next person will see it.