Spot the LangGraph state bug that drops parallel worker results on the floor

Spot the error·Hard·4.0 · 0·~2 min·Asked atCoinbase Hebbia Jasper

Attempt it

Click any words you think contain an error. Click again to unmark.

Mark at least one word to submit.

The bug is in the State definition. `hits: list[str]` tells LangGraph what type the field holds but not how to merge updates from multiple workers. The default merge behaviour is overwrite: whichever worker returns a value last wins, and the rest are silently dropped. In a fan-out scenario where you spawn N parallel research workers and each one returns its own list of hits, you get only one worker's hits in the final state. The other N minus one workers ran, paid for their LLM calls, and produced output that nobody can see. The reducer at the end thinks the workflow found three hits when it actually found thirty. The fix is one line. Change `hits: list[str]` to `hits: Annotated[list[str], operator.add]`. The `Annotated` type hint attaches the `operator.add` function as the per-key reducer. When two parallel workers return `{'hits': [...]}`, LangGraph concatenates the lists instead of overwriting. Every worker's contribution survives. This is one of the most common bugs in LangGraph multi-agent code and it presents almost exactly the same way every time. The reducer at the end of the fan-out reports far fewer items than expected. The fan-out worked; the merge silently dropped everything except the last writer.

**The State definition is missing a reducer for the `hits` field.** A plain `list[str]` annotation tells LangGraph the type but not the merge rule, and the default merge rule is overwrite. When parallel workers each return a partial update for the same key, only the last writer's value survives in the merged state. The fix is to annotate the field with its reducer: ```python from typing import Annotated, TypedDict import operator class State(TypedDict): hits: Annotated[list[str], operator.add] summary: str ``` With `operator.add` attached, LangGraph runs `existing + update` when merging the parallel workers' contributions, which concatenates the lists. Every worker's hits survive the merge. The bug is silent because LangGraph does not warn about missing reducers on multi-update fields. The workflow runs successfully, the per-worker logs show every worker producing output, and only the downstream reducer (which sees, say, three hits instead of the thirty it expected) reveals that something went wrong. The diagnostic is to inspect the post-merge state and compare its size to the per-worker outputs. The broader lesson is that **every accumulating field in a LangGraph state needs an explicit reducer.** Lists of messages, hit collections, score arrays, anything that grows from parallel contributions. Scalar fields (status, counter, last-error) can usually stay on the default overwrite behaviour, but anything that should grow must say so.

TL;DR

The hits field needs Annotated[list[str], operator.add] so parallel workers' contributions concatenate instead of last writer wins clobbering each other.

Memory aid

Easy to grasp

Picture a group project where four students each write a paragraph and submit it to the same shared document. If the document only keeps the most recent paste, only the last student's paragraph survives and the other three are gone. To save everyone's work you need a rule that says append instead of replace. LangGraph's state has the same problem when several agents run in parallel. The fix is to tell the state, in advance, 'for this field, combine the updates by adding them together.' Without that rule, the last worker wins and everyone else's contribution silently vanishes.

Key concepts

Multi-agent systems LLM frameworks Context engineering

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

This is the most reported bug in LangGraph multi-agent code. It shows up almost identically every time: a developer builds a fan-out of N research workers, each worker returns its own contribution to a shared list, and the downstream reducer somehow sees only one worker's data. The fan-out worked. Every worker logged its output. The data simply vanished between the worker's return and the next node's input.

The cause is a one-line omission in the state schema. The cure is a one-line fix. The diagnostic is worth knowing cold because the framework gives no warning and the symptom is silent.

LangGraph's per-key merge contract

Every node in a LangGraph workflow returns a partial state dict. The runtime takes those partial dicts and merges them into the existing state on a per-key basis. The merge rule is the reducer.

Reducers are declared on the state schema, not on the node. For each field in the TypedDict, you can attach a reducer using the Annotated type hint:

python

hits: Annotated[list[str], operator.add]

The first slot is the type (used for type checking). The second slot is the reducer (used at merge time). LangGraph reads the annotation at graph-compile time and wires the reducer into the merge pipeline for that key.

The default is overwrite

If a field has no reducer annotation (plain list[str] instead of Annotated[list[str], operator.add]), LangGraph uses overwrite. The new value replaces the existing value. For most scalar fields (status flags, counters, current-step pointers) this is the right default and is what you want.

For accumulating fields (lists of hits, message logs, score arrays) overwrite is exactly wrong. When two parallel workers each return their own list, overwrite keeps only the last one. The other worker's data is silently discarded.

The framework cannot guess which fields are which from the type alone. Both hits (which should accumulate) and status (which should overwrite) might have type list[str] or str. The annotation is how you tell the framework which semantic you want.

Why the bug is silent

The fix and the reducer-choice question

Catching this in CI and the broader audit pattern

Situations where this technique stops working.

2–4 min · Everything important, quickly.

python

from typing import Annotated, TypedDict
import operator
from langgraph.graph import StateGraph

class State(TypedDict):
    question: str
    hits: Annotated[list[str], operator.add]   # reducer: concatenate
    summary: str                                # reducer: overwrite (default)

def research_worker(state: State) -> State:
    new_hits = retrieve(state['question'])
    return {'hits': new_hits}  # now safely merged across parallel workers

# Custom reducer example for dedup on append:
# def dedup_extend(existing: list[str], update: list[str]) -> list[str]:
#     seen = set(existing)
#     return existing + [x for x in update if not (x in seen or seen.add(x))]
# hits: Annotated[list[str], dedup_extend]

Real products, models, and research that use this idea.

LangGraph's `create_react_agent` prebuilt uses `add_messages` (a custom reducer for chat-message merging) on its messages field, which is the framework-blessed example of the reducer pattern.
Production research-agent workflows at companies like Perplexity-style search products rely on the operator.add reducer for parallel-worker hit collection; the bug shows up in QA when the answer cites fewer sources than expected.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you write a custom reducer that dedups by URL while preserving the order of first appearance?

Take the existing list as a base, iterate the update preserving order, and add each item only if its URL is not already in a seen set built from the existing list. Return the extended list.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Trusting that LangGraph will merge list-typed fields sensibly by default. The default is overwrite; merging requires an explicit reducer annotation per accumulating field.

60 second bullets to scan on the way to the call.

LangGraph's per-key merge contract and the default overwrite semantic
Why a plain list of str type alone is insufficient for accumulating fields

Primary sources. Browse if you want the original framing.