4 of My 18 LLM Calls Were Silently Corrupting My Database. n8n Would Have Caught Them in 5 Seconds.

A few weeks ago I noticed empty fields in production. Not in critical places. Just... there. Blank where something should be. I made a mental note. Moved on. (Admit it, you do the same.)

A week later, still there. So I asked Claude what was going on.

Claude's answer came fast and cheerful, the way a doctor tells you you've been slowly poisoned for a week but you're fine now. "Your LLM calls don't always return all the fields. The response gets parsed anyway, the missing fields become undefined, and JavaScript doesn't complain."

Argh.

That's when the flashback hit. Last year, deep in n8n workflows, I kept hitting broken automations after LLM nodes. Missing data, silent failures, outputs that looked fine until they weren't. I kept patching manually, adding code nodes to check this, check that. Then I stumbled on a LinkedIn post showing a workflow with structured JSON output on the LLM call. In Make. (Yeah. Make and LinkedIn. I know.)

The thing just worked. No patching, no mystery. That was the click — the moment I understood the problem wasn't n8n, it was the contract between me and the LLM output.

I applied it to my n8n workflows immediately. Reliability up. Predictability up. I never connected it to anything else.

Until Claude's cheerful diagnosis landed on my screen.

N8n Showed Me Empty Fields. TypeScript Showed Me Nothing.

Two failure modes. Same root cause. Very different noise levels.

In n8n, when an LLM node returns a malformed or incomplete JSON, one of two things happens. Either the workflow crashes at that node with an explicit error message pointing at exactly what failed. Or it passes through, and you see the empty fields directly in the node output inspector (blank values, right there in the UI, before the data touches anything downstream).

In TypeScript production, same scenario. JSON.parse() succeeds. The object exists. The missing fields are undefined. No exception. No log entry. Nothing in your monitoring. The code returns, the value goes into your database, and your system reports nominal status.

The "less rigorous" tool was noisier about its failures than my production code.

The thing is, n8n isn't doing anything clever. It shows you the data at every step because each node is an object you can inspect. That visibility is a side effect of the architecture. And yet it catches the exact failure mode that TypeScript swallows without a word.

(Caveat: n8n isn't magic either. Hit "Continue on Error" without thinking, skip the Error Branches, and you get exactly the same silence. The visibility is opt-out, not opt-in — but at least you have to actively break it.)

N8n yells. TypeScript whispers. Guess which one is in prod.

I Audited 18 LLM Calls. Here's What I Found.

After the diagnosis, I did what I should have done before shipping any of this: I asked for a full audit. Every LLM call in the codebase. What it returns. What happens to the return value. Whether anything validates the fields before they go anywhere.

18 calls total. The triage came out in three tiers.

Tier 1 — active bombs (4 calls). These write directly to the database. No field validation. On a bad LLM output, undefined goes to the DB, no exception raised, no log, no alert. These were silently corrupting data for days. Nobody noticed because the affected fields weren't displayed in the main UI.

Tier 2 — already handled (8 calls). Some had existing validation. Some had intentional fallbacks. Some returned results immediately checked by the calling code. Not because I planned it (because the features using them happened to care about the output).

Tier 3 — strings only (6 calls). These return raw text. No fields to validate. A bad output means wrong content, not corrupt data. Annoying, but a different class of problem.

The triage principle: fix Tier 1. Everything else is either already handled or not a data integrity issue.

4 bombs out of 18 calls. All silent. None in the logs.

A 2026 analysis from Recall Labs puts silent data failures at 55% of bugs in LLM agent systems (outputs that parse correctly but carry wrong or missing field values). My 4 out of 18 tracks with that. You probably have the same ratio.

The 3-Layer Defense Every LLM Call Needs

Every Tier 1 call gets three layers now. Each catches what the previous one misses. None of this is exotic. It's just the basic plumbing I should have written the first time.

Layer 1 — tell the model what format you want

const response = await openai.chat.completions.create({
  model: "gpt-4o",
  response_format: { type: "json_object" },
  messages: [{ role: "user", content: prompt }]
});

response_format: json_object forces valid JSON syntax. No more "here's your answer, and also here's a JSON block." JSON.parse() stops throwing on malformed responses.

(Caveat: this validates syntax, not schema. Some providers honor it inconsistently. OpenAI is solid, others vary. Layer 1 is a filter, not a guarantee.)

Layer 2 — validate every field you care about

const parsed = JSON.parse(response.choices[0].message.content ?? "{}");

const required = ["product_id", "category", "price_extracted"];
const missing = required.filter(f => parsed[f] === undefined);

if (missing.length > 0) {
  throw new Error(
    `LLM response missing fields: ${missing.join(", ")}. ` +
    `Got keys: ${Object.keys(parsed).join(", ")}. ` +
    `Raw: ${JSON.stringify(parsed).slice(0, 200)}`
  );
}

The error message matters. "LLM validation failed" is useless at 2am. "Missing: price_extracted. Got: product_id, name, description. Raw: {...}" is debuggable. Include what came back, not just what you expected.

Layer 3 — throw, don't swallow

This is the one I got wrong the most. And the one that looks the most harmless:

// the bug
async function extractProductData(text: string) {
  try {
    const result = await callLLM(text);
    return validateAndParse(result);
  } catch (error) {
    console.error("LLM extraction failed:", error);
    return {}; // right here
  }
}

That return {} is your silent corruption. The calling code receives an empty object. It writes to the database. Everything succeeds. No error surfaces. The data is just wrong. And you? You moved on, assuming the LLM behaved. Praying, basically.

// the fix
async function extractProductData(text: string) {
  try {
    const result = await callLLM(text);
    return validateAndParse(result);
  } catch (error) {
    logger.error("LLM extraction failed", { error, context: "product_extraction" });
    throw error;
  }
}

Treat every LLM call like an external API you don't control. Because that's exactly what it is.

JSON.parse() is not validation. Pray is not error handling.

The N8n Parallel: When Your Visual Tool Is More Honest Than Your Code

Visual tools force honesty. Not because they're smarter, but because they have nowhere to hide the data.

In a code function, data flows through variables in memory. You see what you log. If you don't log it, it doesn't exist (until it's wrong in production). In n8n, every node output is a visible object. Click the node, see the data. That's the model.

That structural transparency is why I'd have spotted this in n8n in five seconds, and missed it in TypeScript for a week.

The n8n fix is three changes.

Before: LLM node with default settings. Output goes directly to the downstream node, which accesses .product_id, .category and so on. If the fields aren't there, the node gets undefined. No error unless you've explicitly connected an Error Branch (which most people haven't).

After: First, enable JSON formatting on the LLM node output (a single toggle). Second, add a Code node after the LLM node that checks for required fields and throws explicitly if any are missing. Third, connect the Error Branch to an alert or Stop node (not to "Continue on Error").

The validation Code node in n8n is the same logic as Layer 2 in TypeScript. Same check, same error message, same principle. The difference: you can see it in the workflow diagram without reading a single line of code.

(I built most of this workflow after learning that Claude Code can generate complete n8n workflows from a text description. Turns out "generate a workflow with proper validation nodes" is a perfectly valid prompt when Claude knows the n8n schema.)

In n8n, validation is a node you can see. In code, it's a line you forget.

The Anti-Pattern Hall of Fame

Three patterns. You've written at least one of them.

1. The Optimistic Destructure

const { product_id, category, price } = JSON.parse(llmResponse);
// price is undefined. You just don't know yet.

Why it kills you: JavaScript destructuring never throws on missing keys. (You'll find out on a Friday afternoon, right before leaving to watch dolphins. Of course.) You get undefined and the code keeps running. The failure surfaces three layers later or never.

2. The Silent Catch

} catch (e) {
  return {}; // "fallback"
}

Why it kills you: this isn't a fallback. It's a data corruption route with a reassuring comment. Every return {} in an LLM handler is a place where the contract between you and the model breaks without anyone noticing.

3. Trusting Access

const result = await extractData(text);
await db.products.update({ id, data: result }); // result might be {}

Why it kills you: you're trusting that the function above validated everything. Maybe it did last month. Maybe someone "simplified" it. Database writes need field validation at the write point, not somewhere upstream.

The 5-point checklist (screenshot this):

• Every LLM call writing to DB uses response_format: json_object or equivalent
• Every parsed response validates required fields explicitly before use
• Error messages include what was returned, not just what was expected
• No catch block in an LLM handler returns an empty object or null silently
• Error branches are connected (n8n) or exceptions propagate (TypeScript)

The return {} is the most expensive bug you've never seen.

Vibe Coding Doesn't Remove the Plumbing. It Just Makes It Invisible.

The problem isn't that Claude Code generates bad TypeScript. It doesn't. When I asked it to audit my LLM calls, it found everything and fixed everything correctly.

The problem is that I didn't ask. For months. It's like a slow water leak behind a wall. No flood, no alarm. Just a bill that creeps up over weeks until one day you look at the number and think "wait, that can't be right." Then you start looking. Then you find the damage. The leak was there the whole time (you just had no reason to open the wall).

There's something specific about how we build now. Vibe coding, visual tools, AI-assisted development... they all shift the mental model away from "I know exactly what runs in production" toward "it works, ship it." That shift is mostly fine. But it has a blind spot.

When you move fast and don't read the generated code closely (and I explicitly don't read my own code much, that's not a complaint, that's the workflow), the plumbing disappears from your mental map. You know what features exist. You don't know how the I/O boundaries are handled. You especially don't know about the validation that wasn't written because you didn't specify it in your prompt.

Claude Code is almost too good at this. It fixes things quietly, moves on, keeps going. That's often exactly what you want. But sometimes it's how a bug lives rent-free in your DB for a week without a single error in the logs.

N8n forces the plumbing back into view because the plumbing is the workflow. You can't hide a missing validation node. It either exists on the diagram or it doesn't.

The partial answer I use now: explicit prompt contracts that define the I/O contract for every LLM call. It doesn't solve the visibility problem (you still can't see the contract in a diagram) but it at least forces the contract to exist before the code gets generated.

The gap that's still open: validation needs to be as visible as data. For n8n, that's a node on the diagram. For code, nobody has built that layer yet. Until they do, we have to be loud 🎺 where the LLMs are silent.

Vibe coding didn't kill the silent bugs. It just moved them somewhere you're less likely to look.

---

Sources

• Recall Labs, "Silent Failures in LLM Agent Systems" (March 2026)
• OpenAI structured outputs documentation: platform.openai.com/docs/guides/structured-outputs

---

If the checklist caught a Tier 1 bomb in your codebase, subscribe. I find these the hard way so you don't have to (and I only publish when there's something worth saying).

(*) The cover is AI-generated. It didn't miss any fields.

---

Silent LLM failures can quietly corrupt your production data—learn how to catch them before they become systemic issues.

→ Get the Production Debug Kit