new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

LangChain · LangGraph · all subjects

fault-tolerance

73 notes in this subject, read out of this brain and free to use. This is page 2 of 2.

Version requirements for fault tolerance features

Per-node timeouts and node-level error handlers require langgraph>=1.2 (Python) or @langchain/langgraph>=1.4.0 (JavaScript). Graceful shutdown (RunControl, request_drain/requestDrain, GraphDrained) requires langgraph>=1.2 (Python) or @langchain/langgraph>=1.4.0 (JavaScript).

Resuming after an error in entrypoint

To resume after an error, run the entrypoint with None (Python) or null (JavaScript) and the same thread id in config. This assumes that the underlying error has been resolved and execution can proceed successfully.

Idempotency for task retry handling

Idempotency ensures that running the same operation multiple times produces the same result. This helps prevent duplicate API calls and redundant processing if a step is rerun due to a failure. Always place API calls inside tasks functions for checkpointing and design them to be idempotent in case of re-execution. This is particularly important for operations that result in data writes. When a workflow resumes LangGraph replays completed task results from the checkpoint. A task that started but did not finish may run again on that resume so design side effects to be idempotent. Use idempotency keys or verify existing results to avoid unintended duplication.

Error handling strategies by error type

Transient errors (network issues, rate limits): Use retry policy for automatic retry. LLM-recoverable errors (tool failures, parsing issues): Store error in state and loop back so LLM can adjust. User-fixable errors (missing information, unclear instructions): Pause with interrupt(). Recoverable failure after retries: Run error_handler for compensation/recovery branch. Unexpected errors: Let them bubble up for debugging.

RetryPolicy configuration for transient errors

Add retry_policy to nodes for automatic retry of transient failures. Python example: workflow.add_node("search_documentation", search_documentation, retry_policy=RetryPolicy(max_attempts=3, initial_interval=1.0)). JavaScript example: workflow.addNode("searchDocumentation", searchDocumentation, { retryPolicy: { maxAttempts: 3, initialInterval: 1.0 } }).

LLM-recoverable errors: store error in state and loop back

When a tool fails, store the error message in state and return Command to loop back to the LLM. The LLM can see what went wrong and try a different approach. Example: catch ToolError, return Command(update={"tool_result": f"Tool error: {str(e)}"}, goto="agent").

Unexpected errors should bubble up for debugging

Don't catch unexpected errors. Let them surface so they can be debugged. Only catch and handle errors you know how to recover from.

Error handler for saga/compensation after retry exhaustion

Use error_handler parameter on add_node to run recovery function after retries exhausted. Requires langgraph>=1.2. Example: workflow.add_node("charge_payment", charge_payment, retry_policy=RetryPolicy(max_attempts=3, retry_on=ConnectionError), error_handler=payment_error_handler). error_handler receives state and NodeError, returns Command with updated state and goto compensation branch.

Handle search API errors gracefully by storing error message

When SearchAPIError occurs in search_documentation node, catch it and store error message in search_results: [f"Search temporarily unavailable: {str(e)}"] instead of crashing. Continue to draft_response so LLM can work with degraded information.

RetryPolicy for task and entrypoint resilience

RetryPolicy can be applied to @task and @entrypoint decorators to automatically retry on specific errors. Configure retry_on parameter to specify which exceptions trigger retries. Default RetryPolicy is optimized for retrying specific network errors.

Task timeouts in Functional API

Use the timeout parameter with @task or @entrypoint to limit how long an async attempt can run, specified in seconds or as datetime.timedelta. When exceeded, NodeTimeoutError is raised. Timeouts apply to each retry attempt independently. Only supported for async functions; raises error if set on sync functions.

Example: retry policy with ValueError

Example creating RetryPolicy(retry_on=ValueError), applying to @task get_info(), which fails on first attempt (raises ValueError) then succeeds. Shows how retry_policy automatically retries task on configured exception types.

Example: task timeout with NodeTimeoutError

Example with @task(timeout=1.0) call_api() that sleeps 2 seconds, raising NodeTimeoutError. Shows retry_policy can retry TimeoutError. Demonstrates async timeout behavior and exception handling.

Give your agent this brain