Redis Timeout connecting to server — does Agent Server handle automatic reconnection/retry?

LangSmith Product Help
1

Hi LangGraph team,

We are occasionally seeing Redis connection timeouts from our LangGraph API / Agent Server Queue:

redis.exceptions.TimeoutError: Timeout connecting to server

Our LangGraph deployment and Redis are running on Kubernetes.

One possible scenario we are investigating is Redis pods being restarted/rescheduled during Kubernetes maintenance or patching. In that situation, Redis masters/endpoints may temporarily become unavailable or change while the LangGraph pods are still running.

We would therefore like to understand how Redis connection failures are handled internally by LangGraph Agent Server.

In particular:

  1. Is there already an automatic Redis reconnection/retry mechanism?
    • If an existing Redis connection becomes invalid because a Redis pod/master moved or restarted, will LangGraph automatically establish a new connection?
    • Does the Redis client/pool automatically recover from this situation?
  2. What happens after a redis.exceptions.TimeoutError?
    • Is the failed connection discarded from the pool?
    • Will the next operation attempt to establish a fresh connection?
    • Or can the LangGraph pod remain in a state where subsequent Redis operations continue failing?
  3. Are there recommended Redis configuration parameters for this scenario?
    For example, connection timeout, socket timeout, retry policy/backoff, health checks, or connection pool settings.
  4. If automatic recovery is not currently handled, what is the recommended approach?

We were considering something along the lines of a bounded retry/reconnect strategy, for example:

Redis connection failure
        ↓
wait 30 seconds
        ↓
reconnect / retry
        ↓
maximum 3 attempts
        ↓
still failing → fail/crash the LangGraph pod

The idea would be to avoid infinite retries while still allowing the application to recover automatically from temporary Redis unavailability caused by Kubernetes pod rescheduling/failover. If Redis remains unreachable after the retry window, crashing the pod would allow Kubernetes to restart it cleanly.

Is this already handled by LangGraph / the underlying Redis library, or is there some configuration or application-level logic we should add?

Any guidance on the expected behavior and recommended production configuration for Redis running on Kubernetes would be appreciated.

Thanks!

2

Hi @gdrouet, short answer: Agent Server already retries Redis connection errors, so you usually don’t need custom reconnect logic in your app.

Since v0.5.7, it uses a retry-enabled Redis client instead of a no-retry one: Agent Server changelog. The self-hosted docs also say Redis communication is retried for retry-able errors: Disaster recovery, Redis.

For transient blips during a Redis restart, the server should recover on the next operation. Redis here is only used for pub/sub and queue signaling, durable state lives in Postgres: Agent Server, Task queue.

The main thing to check on Kubernetes is what your REDIS_URI points at. If it’s a pod IP or something that moves when Redis reschedules, retries won’t help much. Point it at a stable endpoint (Service DNS, Sentinel, or managed Redis): Connect external Redis.

For production tuning:

Your crash-after-3-retries idea is fine as an infra safety net, but it shouldn’t be necessary if Redis is HA and the URI is stable.

If you share your Agent Server version and how Redis is deployed, happy to sanity-check the setup.