DOCSEARCHbyAlgolia
Submit Docs

LangGraph Redis

repository·main·Indexed 42 days ago

https://github.com/redis-developer/langgraph-redis

Redis-backed implementations for LangGraph, featuring the langgraph-checkpoint-redis package (v0.5.2). Provides Checkpoint Savers (RedisSaver, AsyncRedisSaver, ShallowRedisSaver) for state management, RedisStore for key-value and vector data, and middleware for semantic caching, tool result caching, and conversation memory.

Tokens
66.1K
Snippets
190
Records
255
Agent score
52%

What's inside LangGraph Redis

  1. Overview of Redis LangGraph Notebook Contents

    main

    The examples directory contains several Jupyter notebooks demonstrating different LangGraph persistence and agentic patterns using Redis:

    • Persistence Patterns:

      • persistence-functional.ipynb: Usage of RedisSaver and functional persistence.
      • subgraph-persistence.ipynb: Persistence within subgraphs.
      • subgraphs-manage-state.ipynb: Managing state in subgraphs.
      • cross-thread-persistence.ipynb: Cross-thread persistence capabilities.
      • cross-thread-persistence-functional.ipynb: Functional cross-thread persistence.

    • Agentic Patterns:

      • create-react-agent-memory.ipynb: Creating agents with persistent memory.
      • create-react-agent-manage-message-history.ipynb: Managing conversation history in a ReAct agent.

    • Human-in-the-loop (HITL):

      • create-react-agent-hitl.ipynb: HITL capabilities with Redis.
      • human_in_the_loop/*.ipynb: Various HITL interaction patterns.

  2. Overview of langgraph-checkpoint-redis features

    main

    The langgraph-checkpoint-redis package provides several key capabilities for LangGraph developers:

    • Checkpoint Savers: Supports full and shallow variants, both synchronous and asynchronous, featuring automatic TTL (Time-To-Live).
    • Stores: Provides key-value storage with optional vector search capabilities for semantic retrieval.
    • Middleware: Enables semantic caching, tool result caching, conversation memory, and semantic routing.
    • Cluster Support: Automatically detects and handles Redis Cluster, Azure Managed Redis, and Redis Enterprise.
    • TTL Management: Utilizes native Redis TTL with features like refresh-on-read and per-thread pinning.

  4. Use Redis-backed middleware for LangGraph workflows

    main

    The langgraph-redis middleware provides specialized capabilities for LangGraph agent workflows by leveraging Redis. Available implementations include:

    • Semantic Cache: SemanticCacheMiddleware for caching semantic queries.
    • Tool Result Cache: ToolResultCacheMiddleware for caching outputs from tools.
    • Conversation Memory: ConversationMemoryMiddleware for managing agent conversation history.
    • Semantic Routing: SemanticRouterMiddleware for routing based on semantic meaning.
    • Middleware Stacking: MiddlewareStack to compose multiple middleware layers together.

  5. What is Middleware in langgraph-checkpoint-redis?

    main
    The langgraph-checkpoint-redis library provides a middleware system for LangGraph agents that intercepts model and tool calls. This allows you to add capabilities like caching, routing, and memory, all backed by Redis. The middleware implements the LangChain AgentMiddleware protocol and is compatible with create_agent and LangGraph's prebuilt agents.

  6. What is checkpointing in LangGraph Redis

    main

    Checkpointing is the mechanism used to persist LangGraph state to durable storage. By implementing the BaseCheckpointSaver interface using Redis, langgraph-checkpoint-redis enables several critical features:

    • Conversation continuity: Resuming conversations from a previous state.
    • Human-in-the-loop: Pausing execution at interrupt points for human approval and resuming from the saved state.
    • Fault tolerance: Recovering from process crashes by restarting from the last committed checkpoint.
    • Debugging: Inspecting the full history of state transitions for a specific thread.

  7. Understand Tool Result Caching vs. Semantic Caching

    main

    The project distinguishes between two types of caching to ensure correctness:

    1. Tool Result Caching: Uses exact match logic. Because tool calls are deterministic (the same arguments must produce the same result), it uses direct Redis GET/SET operations with a generated key. This prevents 'false hits' where similar-looking but different arguments (e.g., page=1 vs page=2) might otherwise return the wrong data if using vector similarity.

    2. Semantic Caching (SemanticCacheMiddleware): Uses vector embeddings and semantic similarity. This is appropriate for LLM response caching, where different user prompts with the same meaning (e.g., "What is Python?" and "Tell me about Python") should share a cached response.

    Key Rule: Use exact matching for tools to avoid returning incorrect data for slightly different arguments.

  8. What are LangGraph Stores and how do they differ from Checkpoints?

    main

    LangGraph Stores provide persistent key-value storage that is independent of graph execution history. While Checkpoints capture per-thread, per-step state (tied to a specific conversation), Stores hold long-lived, cross-thread shared memory.

    Use a Store when data needs to outlive a single conversation or be accessible from multiple concurrent threads, such as user profiles, learned preferences, or shared knowledge.

    FeatureCheckpointsStores
    ScopePer-thread execution historyCross-thread shared memory
    LifetimeTied to a conversation threadIndependent of any thread
    Access patternSequential (latest or by ID)Random (by namespace and key)
    Use caseConversation state, resumptionUser profiles, learned preferences, shared knowledge

  9. Understand the ToolResultCacheMiddleware cacheability decision chain

    main

    The ToolResultCacheMiddleware follows a 7-level priority chain to determine if a tool call should be cached:

    1. metadata["cacheable"]: Explicit override in tool metadata.
    2. metadata["destructive"]: Tools marked destructive are never cached.
    3. metadata["volatile"]: Tools marked volatile are never cached.
    4. metadata["read_only"] and metadata["idempotent"]: Tools meeting both criteria are cached.
    5. Side-effect prefix: Tool names starting with send_, delete_, create_, update_, remove_, write_, post_, put_, or patch_ are never cached.
    6. Volatile argument names: If arguments contain keys like timestamp, current_time, or now (at any nesting depth), the call is not cached.
    7. Config whitelist/blacklist: Falls back to cacheable_tools (whitelist) or excluded_tools (blacklist) from the middleware configuration.

  10. Understand Redis key patterns and prefixes

    main

    The library uses deterministic key patterns for data storage. You can customize these patterns by passing prefix parameters (e.g., checkpoint_prefix, checkpoint_write_prefix, store_prefix, vector_prefix) to the component constructors. This allows multiple independent instances to coexist on the same Redis deployment.

    Default Key Patterns:

    Data TypeKey Pattern
    Checkpointcheckpoint:{thread_id}:{namespace}:{checkpoint_id}
    Checkpoint blobcheckpoint_blob:{thread_id}:{namespace}:{channel}:{version}
    Checkpoint writecheckpoint_write:{thread_id}:{namespace}:{checkpoint_id}:{task_id}
    Store itemstore:{uuid}
    Store vectorstore_vectors:{uuid}

  11. Understand the LangGraph Redis package structure

    main

    The langgraph-checkpoint-redis library is organized into three primary packages, each serving a different role in LangGraph persistence and augmentation:

    • langgraph.checkpoint.redis: Provides checkpoint savers that persist graph state at every superstep.
    • langgraph.store.redis: Provides key-value stores with optional vector search capabilities for long-lived, cross-thread memory.
    • langgraph.middleware.redis: Provides agent middleware for tasks like caching, memory injection, and semantic routing.

  12. Use `default_ttl` and `refresh_on_read` to manage data expiration

    main

    The ttl configuration dictionary supports two primary keys:

    • default_ttl: An integer representing the default time-to-live in minutes for all keys managed by the component. Every key created will have a Redis EXPIRE command applied.
    • refresh_on_read: A boolean. When set to True, reading a checkpoint refreshes its TTL back to the full default_ttl value. This keeps actively used data alive while allowing idle data to expire. If False (or omitted), a checkpoint expires at T + default_ttl regardless of how many times it is accessed.
    # All checkpoints expire after 24 hours (no refresh on read)
ttl={"default_ttl": 1440}

# Checkpoints expire after 1 hour of inactivity
ttl={"default_ttl": 60, "refresh_on_read": True}