Runnable that retries a Runnable if it fails.
Runnable that delegates calls to another Runnable with a set of **kwargs.
Use only if creating a new RunnableBinding subclass with different __init__
args.
See documentation for RunnableBinding for more details.
Configuration for a Runnable.
Custom values
The TypedDict has total=False set intentionally to:
merge_configsvar_child_runnable_config (a ContextVar that automatically passes
config down the call stack without explicit parameter passing), where
configs are merged rather than replaced# Parent sets tags
chain.invoke(input, config={"tags": ["parent"]})
# Child automatically inherits and can add:
# ensure_config({"tags": ["child"]}) -> {"tags": ["parent", "child"]}Async callback manager for chain run.
Callback manager for chain run.
Parameters for tenacity.wait_exponential_jitter.
Retry a Runnable if it fails.
RunnableRetry can be used to add retry logic to any object that subclasses the base Runnable.
Such retries are especially useful for network calls that may fail due to transient errors.
The RunnableRetry is implemented as a RunnableBinding. The easiest
way to use it is through the .with_retry() method on all Runnables.
Example: Here's an example that uses a RunnableLambda to raise an exception
import time
def foo(input) -> None:
'''Fake function that raises an exception.'''
raise ValueError(f"Invoking foo failed. At time {time.time()}")
runnable = RunnableLambda(foo)
runnable_with_retries = runnable.with_retry(
retry_if_exception_type=(ValueError,), # Retry only on ValueError
wait_exponential_jitter=True, # Add jitter to the exponential backoff
stop_after_attempt=2, # Try twice
exponential_jitter_params={"initial": 2}, # if desired, customize backoff
)
# The method invocation above is equivalent to the longer form below:
runnable_with_retries = RunnableRetry(
bound=runnable,
retry_exception_types=(ValueError,),
max_attempt_number=2,
wait_exponential_jitter=True,
exponential_jitter_params={"initial": 2},
)
This logic can be used to retry any Runnable, including a chain of Runnables, but in general it's best practice to keep the scope of the retry as small as possible. For example, if you have a chain of Runnables, you should only retry the Runnable that is likely to fail, not the entire chain.