[KongchangAI]
· 1 min read· 736 words

LangChain Core 1.6.9 Released: with_retry Now Supports Callable Arguments

LangChain Core 1.6.9 Released: with_retry Now Supports Callable Arguments

langchain-core 1.6.9 adds callable support to with_retry for dynamic retry logic.

langchain-core 1.6.9 is a minor update to LangChain's core library. The headline change is that the `with_retry` method now accepts callable arguments, letting developers pass in functions to dynamically determine retry behavior instead of relying solely on static configuration. This is practically valuable for production LLM applications — when facing rate limits, network instability, or server errors, programmable retry logic can adapt based on exception content and runtime context, significantly improving fault tolerance. The release is built and signed by GitHub Actions, carries low backward-compatibility risk, and is worth adopting for teams with heavy external API dependencies.

Release Overview

The langchain-core module — the foundational layer of the LangChain ecosystem — has released version 1.6.9, automatically built by GitHub Actions and published with GitHub's verified signing. This is a minor iteration following 1.6.8, focused primarily on enhancing the flexibility of the retry mechanism.

As the base dependency for the entire LangChain framework, langchain-core underpins critical capabilities such as the Runnable interface, message abstractions, and the callback system. Nearly every higher-level component depends on it. Even a minor version update like this is worth paying attention to for developers building applications with LangChain.

langchain-core 1.6.9 release page

Core Change: with_retry Accepts Callable Arguments

The most notable change in this release is that with_retry can now accept a callable as an argument (PR #41158).

Previously, with_retry controlled retry behavior through fixed configuration parameters — such as the number of retries or which exception types should trigger a retry. With the introduction of callable support, developers can now pass in a function to dynamically determine whether a retry should be triggered, enabling finer-grained control in complex scenarios.

What This Means in Practice

In real production environments, calls to large language model APIs frequently encounter rate limits, transient network issues, or server-side errors. A static retry strategy — such as "retry exactly 3 times" — often falls short in handling all situations. By allowing callables to be passed in, developers can:

  • Decide whether to retry based on the specific type or content of an exception
  • Dynamically adjust strategy based on runtime context (e.g., the priority of the current request)
  • Implement smarter backoff logic to reduce pressure on downstream services

This change may seem small, but for building robust LLM application pipelines, making retry logic programmable can significantly improve system fault tolerance.

with_retry is a chainable method provided by the LangChain Runnable interface that wraps any Runnable component with retry logic. Its basic usage looks like chain.with_retry(stop_after_attempt=3, retry_if_exception_type=(RateLimitError,)), using declarative configuration to specify the maximum number of retries, the exception types that should trigger a retry, and the wait strategy. Under the hood, it relies on the tenacity library for backoff and termination logic. Prior to 1.6.9, all retry conditions had to be declared statically at call time — there was no way to make differentiated decisions at runtime based on specific error content or context.

Release and Signing

This version was published by github-actions at commit hash fc7dc77, signed using GitHub's verified signing mechanism (GPG key ID: B5690EEEBB952194). A signed release means developers can verify the authenticity of the artifact's origin — a fundamental safeguard at a time when software supply chain security is increasingly under scrutiny.

The version itself follows the release(core): 1.6.9 release process (PR #41160), continuing LangChain's standardized versioning practices.

Software supply chain security has gained widespread attention in recent years following several high-profile open-source package poisoning incidents. GPG signing is a common integrity verification mechanism: the publisher signs the artifact with a private key, and consumers verify the signature using the public key (here, key ID B5690EEEBB952194) to confirm the package was indeed released by the claimed party and has not been tampered with. The GitHub Actions auto-signing model integrates the signing process into the CI/CD pipeline, reducing the risk of key exposure from manual operations and providing an auditable release provenance chain for scenarios like pip install. For teams using open-source dependencies in production, checking whether a dependency has a signing mechanism is increasingly becoming part of the security baseline.

How to Upgrade

For projects already using LangChain, upgrading to this version typically just requires updating the dependency version constraint. Since this is a patch/minor-level update and primarily a feature enhancement (feat), the risk of backward incompatibility is theoretically low. That said, it's recommended to run regression tests on critical retry paths after upgrading to ensure compatibility with existing configurations.

If your application relies heavily on calls to external APIs and you want finer control over failure retries, upgrading to 1.6.9 to take advantage of the new callable retry parameter is a reasonable choice.

Summary

langchain-core==1.6.9 is a pragmatic update focused on improving retry mechanism flexibility. While the changes are modest, the enhancement to with_retry — now supporting callable arguments — directly addresses a real production need: fault tolerance in LLM applications. For teams that prioritize stability, this kind of incremental refinement to foundational capabilities is often more valuable than feature-heavy major releases.

#LangChain Core 1.6.9#with_retry callable#LangChain retry mechanism#LLM application fault tolerance#langchain-core update
Share:

Related articles