- Retries — automatically re-run failed attempts based on exception type and backoff settings
- Timeouts — cap how long a single attempt may run
- Error handling — run a recovery function after all retries are exhausted
set_node_defaults to configure these mechanisms once for all nodes instead of repeating them on every add_node call.
These compose in a fixed order: when a node attempt raises any exception (including NodeTimeoutError from a timeout), the retry policy decides whether to retry. Only after retries are exhausted does the error handler run.
For stopping a run cleanly at a superstep boundary and resuming later, see Graceful shutdown.
Per-node timeouts and node-level error handlers require
langgraph>=1.2.Retries
A retry policy automatically re-runs a failed node attempt based on exception type and backoff settings. Passretry_policy= to add_node:
Default behavior
By default,retry_on uses default_retry_on, which retries on any exception except the following (and their subclasses):
ValueErrorTypeErrorArithmeticErrorImportErrorLookupErrorNameErrorSyntaxErrorRuntimeErrorReferenceErrorStopIterationStopAsyncIterationOSError
requests and httpx, it only retries on 5xx status codes. NodeTimeoutError is retryable by default.
Parameters
| Parameter | Type | Default | Description |
|---|---|---|---|
max_attempts | int | 3 | Maximum number of attempts, including the first. |
initial_interval | float | 0.5 | Seconds before the first retry. |
backoff_factor | float | 2.0 | Multiplier applied to the interval after each retry. |
max_interval | float | 128.0 | Maximum seconds between retries. |
jitter | bool | True | Add random jitter to the interval. |
retry_on | type[Exception] | Sequence[type[Exception]] | Callable[[Exception], bool] | default_retry_on | Exceptions to retry on, or a callable returning True for retryable exceptions. |
Custom retry logic
Pass a callable or exception type toretry_on. Import default_retry_on to extend the default behavior:
Inspect retry state
Use execution info inside a node to inspect the current attempt number. This is useful for switching to a fallback when the primary call keeps failing:execution_info exposes the following fields:
| Attribute | Type | Description |
|---|---|---|
node_attempt | int | Current attempt number (1-indexed). 1 on the first try, 2 on the first retry, etc. |
node_first_attempt_time | float | None | Unix timestamp of when the first attempt started. Constant across retries. |
thread_id | str | None | Thread ID for the current execution. None without a checkpointer. |
run_id | str | None | Run ID for the current execution. None when not provided in config. |
checkpoint_id | str | Checkpoint ID for the current execution. |
task_id | str | Task ID for the current execution. |
execution_info is available even without a retry policy—node_attempt defaults to 1.
Timeouts
Requires
langgraph>=1.2.timeout= parameter on add_node caps how long a single node attempt may run. Pass a number (seconds), a timedelta, or a TimeoutPolicy for separate run and idle limits:
Run timeout
run_timeout is a hard wall-clock cap on a single attempt. It is never refreshed, regardless of node activity:
NodeTimeoutError, clears any writes from the failed attempt, and lets the retry policy decide whether to retry.
Idle timeout
idle_timeout is a progress-resetting cap. It fires only when the node stops making observable progress for the specified duration—unlike run_timeout, the clock resets whenever the node produces a progress signal:
run_timeout and idle_timeout together. Whichever fires first cancels the attempt.
Progress signals
Under the defaultrefresh_on="auto", the idle clock resets on any of the following:
- State writes via
CONFIG_KEY_SEND - Stream output (yielded async stream chunks)
- Child-task scheduling
- Runtime stream-writer calls
- Any LangChain callback event from the node or its descendants (LLM tokens, tool calls, chain start/end, etc.)
Heartbeat mode
Setrefresh_on="heartbeat" to narrow the refresh source to explicit runtime.heartbeat() calls only. This is useful when you want a strict idle definition that isn’t reset by chatty subordinates:
Manual heartbeats
For long-running work that doesn’t naturally emit progress signals, callruntime.heartbeat() to manually reset the idle clock:
runtime.heartbeat() is a no-op outside an idle-timed attempt, so you can call it unconditionally.
NodeTimeoutError
When a timeout fires, LangGraph raisesNodeTimeoutError with structured context about which limit was hit:
| Attribute | Type | Description |
|---|---|---|
node | str | Name of the node whose execution timed out. |
elapsed | float | Seconds elapsed before the timeout fired. |
kind | Literal["idle", "run"] | Which timeout fired. |
idle_timeout | float | None | The configured idle timeout (seconds), if any. |
run_timeout | float | None | The configured run timeout (seconds), if any. |
NodeTimeoutError is retryable by default. Combining timeout with a retry policy works out of the box—the timeout clock resets on each new attempt, and writes from a timed-out attempt are cleared before the next retry:
Dynamic timeouts with Send
When usingSend to dispatch nodes dynamically (for example, in map-reduce patterns), you can pass a timeout directly on the Send to override the target node’s static timeout for that specific push:
Send, the target node’s timeout (set at add_node time) applies. This lets you set a default timeout on the node and tighten it for individual calls.
Error handling
Requires
langgraph>=1.2.Command. This is useful for compensation flows (Saga patterns) where you want to recover gracefully rather than abort the entire graph.
Pass error_handler= to add_node:
NodeError
Error handlers receive failure context through a typederror: NodeError parameter, injected by type annotation (the same pattern as runtime: Runtime):
NodeError is a frozen dataclass with two fields:
| Attribute | Type | Description |
|---|---|---|
node | str | Name of the node whose execution failed. |
error | BaseException | The exception raised by the failed node. |
error: NodeError parameter is opt-in. Handlers that don’t need failure context can use simpler signatures like (state) or (state, runtime).
Route with Command
Error handlers can return aCommand to update state and route to a specific node, enabling Saga / compensation patterns:
charge_payment retries on ConnectionError up to 3 times. If retries are exhausted (or the error isn’t a ConnectionError), the handler compensates by updating state and routing to finalize instead of aborting the graph.
Resume-safe failures
Failure provenance is checkpointed. If the graph is interrupted or the process crashes after a node fails but before the handler completes, the handler sees the same
NodeError context when the graph resumes from its checkpoint.Behavior with interrupt()
Subgraph failures
If a node wraps a subgraph and the subgraph raises an unhandled exception, that exception surfaces to the parent node. If the parent node has an error handler, the handler fires with the subgraph’s exception inerror.error.
Graph defaults
Requires
langgraph>=1.2.retry_policy=, error_handler=, timeout=, or cache_policy= on every add_node call, use set_node_defaults() to configure graph-wide defaults in one place:
step_a and step_b now share the same retry policy, error handler, and timeout without any duplication.
Precedence
Per-node values passed directly toadd_node() always override the defaults set by set_node_defaults(). Defaults are resolved at compile() time, so you can call set_node_defaults() before or after add_node() in any order:
Default error handler
Theerror_handler default is particularly valuable when you want a single catch-all recovery function for any node that fails without its own handler. The handler accepts the same (state, error: NodeError) signature described in Error handling:
default_handler runs. The default handler also accepts RunnableConfig as an optional third argument if you need access to config values such as thread_id:
Applicability matrix
Not all defaults apply to all node types. Error-handler nodes (those registered viaadd_node(error_handler=...)) are excluded from certain defaults to prevent unsafe behavior:
set_node_defaults parameter | Applies to regular nodes | Applies to error-handler nodes | Reason |
|---|---|---|---|
retry_policy | ✅ | ✅ | Handlers should be retried on transient failures |
timeout | ✅ | ✅ | Stuck handlers should be cancelled like stuck regular nodes |
error_handler | ✅ | ❌ | Handlers must never catch themselves |
cache_policy | ✅ | ❌ | Caching handler results is unsafe |
Scope
Defaults set on a parent graph are not inherited by subgraphs. Each graph maintains its own defaults.Functional API
The sametimeout= and retry_policy= parameters are available on @task and @entrypoint in the functional API:
add_node: NodeTimeoutError is raised on timeout, buffered writes are cleared, and the retry policy decides whether to retry.
Graceful shutdown
Cooperative shutdown lets you stop an in-flight graph run after the current superstep completes and save a resumable checkpoint. This is useful for handling SIGTERM signals or any external supervisor that needs to reclaim resources without losing work.Requires
langgraph>=1.2.RunControl and pass it as control= to invoke or stream. Call request_drain() from any thread to signal that the run should stop:
Semantics
Drain is cooperative and operates between supersteps, never preempting work that is already running:| Scenario | Behavior |
|---|---|
| Node mid-execution | Runs to completion. Drain takes effect on the next superstep. |
| Node with a retry policy currently retrying | Retry loop runs to exhaustion or success. Drain takes effect after. |
| Graph finishes naturally on the same tick as drain | Returns normally. Inspect control.drain_requested to distinguish from a normal run. |
| More supersteps remain | Raises GraphDrained(reason). Checkpoint is saved and resumable. |
| Subgraph requests drain | GraphDrained bubbles up through the parent and stops it at its own next superstep boundary. |
Resume after drain
Resume a drained run withinvoke(None, config) using the same thread_id:
Read drain state inside a node
Access drain state through theruntime parameter to adjust node behavior before the superstep boundary is reached:
SIGTERM hook pattern
The recommended pattern for handling process shutdown:request_drain() does not cancel running asyncio tasks or kill threads. For a hard upper bound, pair drain with a graceful timeout and task cancellation.Limitations
- Timeouts are async-only: sync nodes with a
timeoutare rejected at compile time. - One handler per node: each node can have at most one
error_handler. - Handler failures bubble up: if the error handler itself raises, that exception propagates as if the node had no handler.
set_node_defaultsis not inherited by subgraphs: each graph manages its own defaults independently.
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

