The Empty AI Response Stored as a Literal String

# The Empty AI Response Stored as a Literal String A client's customer-facing reports were occasionally showing up with the exact text "No response generated" where an AI-written analysis section should have been. Support had noticed it a few times and assumed it was a rare rendering glitch. It wasn't rendering. It was the literal string a fallback handler had written into the database, and it had been shipping to real customers for a while before anyone traced it back. ## Where the empty response actually came from The integration used a reasoning-capable model where the reasoning tokens draw from the same output budget as the final answer. On prompts that required more reasoning than usual, the model would spend its entire allotted budget thinking and have nothing left to produce as visible output — a legitimate, documented failure mode of that model class, not a bug in the model itself. The application code, however, treated an empty response the same way it treated a normal one: it took whatever string came back, and when that string was empty, a fallback somewhere upstream substituted a placeholder — "No response generated" — and that placeholder got persisted as if it were real content. The bug wasn't the empty response. Reasoning budgets get exhausted; that's expected and recoverable. The bug was building a fallback whose failure mode was silent data corruption instead of a visible, catchable error. ## The fix had three independent parts Raising the token budget reduced how often the exhaustion happened, but a rare occurrence you can't fully eliminate isn't safe to handle with "make it rarer." So the fix also added a retry — if the response comes back empty once, try again before giving up, since a second attempt often succeeds even when the first didn't. And critically, the final fallback path was changed to throw an error rather than store a placeholder string. If the second attempt is also empty, the system now fails loudly, upstream of the database, instead of writing fabricated-looking content into a customer-facing record. A request timeout was added at the same time, closing an adjacent gap where a hung call had no bound at all. ## Why "it looked done" isn't the same as "it degrades safely" This is the failure mode I actively look for now in any AI-integrated feature: not "does it work most of the time," which is usually true and usually easy to demo, but "what does the system do on the input that breaks it, and does that failure look like a failure." A crash is honest. A timeout is honest. A plausible-looking placeholder string persisted into a customer record is the worst outcome available, because it passes every casual review — the report generated, the page rendered, the field wasn't null — while quietly lying about what happened. When I review AI-integrated code now, I ask specifically what the handler does on an empty, malformed, or truncated model response, and I ask it before I ask what the handler does on a good one. The happy path is usually fine. The failure path is where fabricated content gets a stamp of legitimacy it never earned, and it's disproportionately the part nobody wrote a test for.