How to Fix 'intermittent 500 errors in production' in LangGraph (TypeScript)

Intermittent 500s in LangGraph usually mean your graph is failing only on certain inputs, concurrency paths, or runtime conditions. In TypeScript, the root cause is often not “LangGraph itself” but a bad state shape, a node that throws sometimes, or a side effect that isn’t safe under retries and parallel execution.

If you’re seeing this in production, treat it like a graph execution bug first and an API bug second. The stack trace usually points at CompiledStateGraph.invoke(), RunnableSequence.invoke(), or a node function that returned something LangGraph could not merge into state.

The Most Common Cause

The #1 cause is returning an invalid partial state from a node.

LangGraph expects each node to return an object that matches your state schema. If a node sometimes returns undefined, a primitive, or a shape that conflicts with the reducer, you’ll get runtime failures like:

• •InvalidUpdateError: Expected node to return an object
• •InvalidUpdateError: Invalid update for key "messages"
• •TypeError: Cannot read properties of undefined
• •Error: Graph execution failed

Here’s the broken pattern:

const State = Annotation.Root({ messages: Annotation<string[]>({ reducer: (left, right) => left.concat(right), default: () => [], }), });

const graph = new StateGraph(State) .addNode("classify", async (state) => { if (state.messages.length === 0) return; // ❌ invalid if (state.messages[0].includes("refund")) { return "refund"; // ❌ invalid } return { messages: ["ok"] }; }) .addEdge("start", "classify") .compile(); |ts import { StateGraph, Annotation } from "@langchain/langgraph";

const State = Annotation.Root({ messages: Annotation<string[]>({ reducer: (left, right) => left.concat(right), default: () => [], }), route: Annotation<string | null>({ reducer: (_left, right) => right, default: () => null, }), });

const graph = new StateGraph(State) .addNode("classify", async (state) => { if (state.messages.length === 0) { return { route: null }; // ✅ valid partial update }

if (state.messages[0].includes("refund")) {
  return { route: "refund" }; // ✅ valid object
}

return { route: "default" };

}) .addEdge("start", "classify") .compile();

The important rule is simple: every node must always return an object compatible with the state definition. If you need branching, write to a routing field and use conditional edges instead of returning raw strings or `undefined`.

## Other Possible Causes

### 1. Non-idempotent side effects inside nodes

If a node writes to Postgres, Redis, Stripe, or another external system and then throws afterward, retries can turn one failure into multiple writes.

```ts
.addNode("charge", async (state) => {
  await stripe.charges.create({ amount: 1000 }); // side effect
  throw new Error("boom"); // retry causes double charge risk
})

Fix it by making the operation idempotent and storing an idempotency key in state or metadata.

.addNode("charge", async (state) => {
  const key = state.requestId;
  await stripe.charges.create(
    { amount: 1000 },
    { idempotencyKey: key }
  );
  return { charged: true };
})

2. Shared mutable objects across requests

A common TypeScript mistake is reusing arrays or objects outside the graph. Under load, one request mutates data another request is still using.

const sharedMessages: string[] = [];

.addNode("append", async () => {
  sharedMessages.push("hello"); // shared mutable state
  return { messages: sharedMessages };
})

Create fresh objects per invocation.

.addNode("append", async () => {
  const messages = ["hello"];
  return { messages };
})

3. Async nodes that swallow errors inconsistently

If you catch errors and sometimes return malformed data instead of rethrowing, production failures become intermittent and hard to trace.

.addNode("fetchCustomer", async () => {
  try {
    const res = await fetch("https://api.internal/customers/1");
    return { customer: await res.json() };
  } catch {
    return {}; // may break downstream nodes expecting customer
  }
})

Either rethrow or return an explicit error field.

.addNode("fetchCustomer", async () => {
  try {
    const res = await fetch("https://api.internal/customers/1");
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return { customer: await res.json(), error: null };
  } catch (e) {
    return { customer: null, error: String(e) };
  }
})

4. Schema mismatch between TypeScript types and runtime state

TypeScript won’t save you if your runtime payload doesn’t match what your reducers expect.

type State = {
  messages: string[];
};

return { messages: "hello" as any }; // compiles, fails later

Use strict validation at the boundary before entering the graph.

import z from "zod";

const InputSchema = z.object({
  messages: z.array(z.string()),
});

const input = InputSchema.parse(rawInput);

How to Debug It

1. •

   Reproduce with one failing payload

   • •Log the exact input that caused the 500.
   • •Run it locally through .invoke() with the same payload.
   • •If it only fails under load, suspect shared state or side effects.
2. •

   Inspect the node that last executed

   • •Add logs before and after every node.
   • •Look for exceptions like:
     • •InvalidUpdateError
     • •TypeError
     • •Cannot read properties of undefined
   • •The last successful node usually tells you where the bad update entered the graph.
3. •

   Validate every node output

   • •Temporarily wrap nodes with a guard:

   const safeNode = async (fn) => async (state) => {
     const result = await fn(state);
     console.log("node result", result);
     if (!result || typeof result !== "object" || Array.isArray(result)) {
       throw new Error("Node returned invalid update");
     }
     return result;
   };
   

   • •This catches silent bad returns before LangGraph merges them.
4. •

   Disable concurrency and retries temporarily

   • •If failures disappear when you serialize execution, you likely have race conditions.
   • •Check any parallel branches writing to the same key without reducers.
   • •Make sure reducers are associative and safe for concurrent updates.

Prevention

• •Keep node outputs boring:
  • •always return plain objects
  • •never return primitives or undefined
• •Make all external writes idempotent:
  • •use request IDs
  • •store dedupe keys in state or metadata
• •Validate inputs at the edge:
  • •use Zod before .invoke()
  • •reject malformed payloads early instead of letting them explode mid-graph

If you’re seeing intermittent 500 errors in production with LangGraph TypeScript, start by checking node return shapes. In practice, that’s where most “works locally, fails randomly in prod” bugs come from.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.