Skip to main content
Nodes are the steps of a Graph API graph. This page covers how to attach runtime configuration, retries, timeouts, error handlers, defaults, and caching when you add a node. For wiring nodes into sequences, branches, and loops, see Control flow. For the full retry, timeout, and error lifecycle, see Fault tolerance.

Add runtime configuration

Pass values into a run (for example, which LLM or system prompt to use) without putting those values in graph state. To add runtime configuration:
  1. Specify a schema for your configuration
  2. Add the configuration to the function signature for nodes or conditional edges
  3. Pass the configuration into the graph
See below for a simple example:
Choose OpenAI or Anthropic at invoke time. These examples call live providers and need API keys.
Configure both the model provider and a system message at invoke time. These examples call live providers and need API keys.

Add retry policies

Attach a retry policy when a node calls an API, database, or LLM that can fail transiently. Pass retry_policy to add_node. The value is a RetryPolicy named tuple. This example uses the defaults:
By default, retry_on uses default_retry_on, which retries any exception except:
  • ValueError
  • TypeError
  • ArithmeticError
  • ImportError
  • LookupError
  • NameError
  • SyntaxError
  • RuntimeError
  • ReferenceError
  • StopIteration
  • StopAsyncIteration
  • OSError
For exceptions from popular HTTP libraries such as requests and httpx, it only retries on 5xx status codes. See Fault tolerance for the full default list and parameters.
These snippets show how to attach different retry policies. They do not create database tables or invoke the graph.Pass different retry policies to a model node and a SQL node:

Set node timeouts

Requires langgraph>=1.2.
Pass timeout to add_node to cap how long a single async node attempt may run. Use a number (seconds), a datetime.timedelta, or a TimeoutPolicy for separate run and idle limits:
Node timeouts apply only to async nodes. Setting timeout on a sync node fails at compile time, because sync Python execution cannot be safely canceled in-process. For separate run and idle limits, pass a TimeoutPolicy. When a node exceeds its timeout, LangGraph raises NodeTimeoutError. It does not subclass built-in TimeoutError (an OSError subclass), so the default retry policy treats it as retryable when a retry_policy is set. The timeout applies to each attempt independently, so the timer resets for every retry. Timed-out attempts do not commit buffered writes. See Fault tolerance for the full timeout lifecycle, idle-timeout refresh sources, and runtime.heartbeat().

Handle node errors

Requires langgraph>=1.2.
Pass error_handler to add_node to run a function after a node fails and all retries are exhausted. The handler receives the current state and a typed NodeError, and can route to a recovery branch via Command:
See Fault tolerance for a full runnable example, compensation patterns, and Command routing.

Set graph-wide node defaults

Requires langgraph>=1.2.
Use set_node_defaults to set retry_policy, timeout, cache_policy, or error_handler once for every node in a graph, instead of repeating them on each add_node call. Per-node values always win, and defaults are applied at StateGraph.compile time:
retry_policy and timeout defaults apply to every node, including error-handler nodes. cache_policy and error_handler defaults apply only to regular nodes—handlers never catch themselves, and caching a handler result is unsafe. Defaults are not inherited by subgraphs. See Fault tolerance for the full precedence rules and applicability table.

Access execution info inside a node

Access execution identity and retry information via runtime.execution_info. This surfaces thread, run, and checkpoint identifiers as well as retry state, without reading from config directly.

Access thread and run IDs

Use execution_info to access the thread ID, run ID, and other identity fields inside a node:

Adjust behavior based on retry state

When a node has a retry policy, use execution_info to inspect the current attempt number and switch to a fallback after the first attempt fails:
execution_info is set once the node task is prepared. Even without a retry policy, node_attempt defaults to 1, and node_first_attempt_time is set when the node starts executing.

Access server info inside a node

When your graph runs on LangGraph Server, you can access server-specific metadata via runtime.server_info. This surfaces the assistant ID, graph ID, and authenticated user without reading config metadata or configurable keys directly.
server_info is None when the graph is not running on LangGraph Server (for example, during local development or testing).
Requires langgraph>=1.1.5.

Access drain state inside a node

When a graceful shutdown has been requested, runtime.drain_requested is True. Read this inside a node to skip expensive work before the next superstep boundary:
Requires langgraph>=1.2. See Graceful shutdown for the full RunControl API.

Add node caching

Use node caching when a step is expensive and you want to reuse results for the same input. To enable caching:
  1. Pass a cache when you compile the graph (for example, InMemoryCache). SqliteCache is also available in Python.
  2. Attach a CachePolicy on the node.
CachePolicy options:
  • key_func: Function that builds a cache key from the node input. Defaults to a hash of the input (via pickle).
  • ttl: Time to live in seconds. When omitted, the cache entry does not expire.
The first run takes about two seconds because of the mocked work. The second run returns from the cache. You can also set cache_policy (and other node options) once for the graph with set_node_defaults. See Set graph-wide node defaults.

See also