Why Did Task B Inherit Task A's Retry Count? LangGraph's Three Data Layers

The article opens with an interview scenario: Task A fails twice ( retry_count=2), then a new Task B fails once but the agent stops, claiming retries exhausted. The root cause is that retry_count was stored in a user-level Store, so Task B read the same user_id and inherited the count. The fix is understanding three distinct data layers in LangGraph (LangChain v1).

The Bug: Retry Count Leaks Across Threads

Task A and Task B run on different thread_id s. retry_count belongs to the execution context of a single thread and should be saved/restored with that thread's checkpoint. Storing it in a user-scoped Store turns a transient thread state into long-term memory, causing cross-thread contamination. The symptom appears only when a second task starts — demonstrating how misplaced data passes initial tests but fails on recovery or new threads.

Three Data Layers: State, Runtime Context, Store

In LangGraph runtime, three data categories coexist:

State — the current task's working context: messages, current_step, retry_count. It mutates during execution. With a checkpointer configured, it persists and restores per thread_id; without a checkpointer it does not survive across invocations.

Runtime Context — identity, configuration, and dependencies injected for this run: user_id, permissions, database clients. Tools and middleware read it, but it does not become thread state just because a checkpointer exists. Its trustworthiness depends on how the application obtains and injects it.

Store — long-term data shared across threads: user preferences, stable facts, shared knowledge. Organized by namespace + key as JSON documents; multiple threads can access the same long-term data.

The practical test for any piece of data: when does it change? How long should it live? What key retrieves it next time? retry_count answers point to State; call identity points to Runtime Context; cross-session language preference points to Store.

Why Both user_id and thread_id Are Required

User user-42 runs Task A and Task B concurrently. thread_id identifies which task instance; it retrieves that thread's messages, intermediate steps, and retry count. user_id identifies the person; placed in Runtime Context (sourced from authentication), it builds the long-term preference namespace: ("users", "user-42", "preferences") Merging the two IDs conflates "who" with "which task", causing thread-state leakage and potential loss of long-term preferences when a new thread starts. The framework allows user_id in custom State, but the author prefers Runtime Context because identity is supplied by auth, immutable during a run, and need not be checkpointed.

Misplaced Data: Silent Until Recovery or New Thread

retry_count

in Store → new task inherits old failures.

User preference only in State → lost when a new thread starts.

Database connection in State → checkpointer tries to serialize it; connection may be invalid after restart.

These bugs stay hidden during a single happy-path demo; they surface on new tasks, process restarts, or checkpoint recovery.

Program Visibility ≠ Model Visibility

Data in Runtime Context (identity, connections) and Store (preferences) are program-accessible but do not automatically enter the model's context. Tools must explicitly read and pass needed values via tool results, messages, or dynamic prompts. Conversely, secrets and DB clients must stay out of prompts. "Agent remembered" requires both persistence and explicit delivery to the right consumer.

Code Example: ToolRuntime Unifies Three Layers

from dataclasses import dataclass
from langchain.tools import ToolRuntime, tool

@dataclass
class Context:
    user_id: str

@tool
def load_writing_style(runtime: ToolRuntime[Context]) -> str:
    step = runtime.state.get("current_step", "unknown")
    namespace = ("users", runtime.context.user_id, "preferences")
    item = runtime.store.get(namespace, "writing_style")
    style = item.value.get("style", "default") if item else "default"
    return f"step={step}; writing_style={style}"

runtime.state

reads thread-scoped step; runtime.context reads injected user_id; runtime.store queries long-term preference by namespace. ToolRuntime is framework-injected and not exposed to the model's tool schema; the model cannot fabricate a user_id. The application must inject trusted auth results.

Invocation: Separate thread_id and user_id

agent.invoke(
    {"messages": [{"role": "user", "content": "继续检查任务"}]},
    config={"configurable": {"thread_id": "task-b"}},
    context=Context(user_id="user-42"),
)

thread_id

goes in config; user_id goes in context. Teaching can use InMemorySaver and InMemoryStore; production requires persistent backends. Full persistence needs state_schema, context_schema, checkpointer, and Store all configured.

Follow-up Interview Questions & Engineering Checks

State updates: retry_count increments on tool failure, not per model thought. Parallel node updates to same field need a reducer, else INVALID_CONCURRENT_GRAPH_UPDATE.

Context source: user_id and permissions from app auth, not from user's natural language claim.

Store isolation: Namespace by user/org; define write authority, TTL, deletion policy. Model's speculative conclusions must not auto-persist.

Model visibility: Only task-essential info enters messages/prompts; program access ≠ model access.

Regression suite: (1) Task A fails twice, reopen A → count restored to 2. (2) Same user new Task B → count starts at 0. (3) Both A and B read same language preference. (4) Different user_id cannot read user-42 's preference. (5) Without persistent backend, restart loses data — don't mistake in-memory for production memory. Assertions check exact fields: B's initial retry_count, A's checkpoint thread_id, Store namespace used, sensitive Context absent from prompts.

In one sentence: with a checkpointer, State persists per thread_id; Runtime Context injects identity/config/dependencies per run; Store holds cross-thread long-term data. Explicitly control who reads, what persists, and what reaches the model. Don't ask if the agent can remember; ask how long this data should live.