diff --git a/src/oss/langgraph/durable-execution.mdx b/src/oss/langgraph/durable-execution.mdx index 1bc7df92c6..c352276d57 100644 --- a/src/oss/langgraph/durable-execution.mdx +++ b/src/oss/langgraph/durable-execution.mdx @@ -52,40 +52,7 @@ how to structure your code using **tasks** to avoid these issues. The same princ ## Durability modes -LangGraph supports three durability modes that allow you to balance performance and data consistency based on your application's requirements. The durability modes, from least to most durable, are as follows: - -* [`"exit"`](#exit) -* [`"async"`](#async) -* [`"sync"`](#sync) - -A higher durability mode adds more overhead to the workflow execution. - - -**Added in v0.6.0** -Use the `durability` parameter instead of `checkpoint_during` (deprecated in v0.6.0) for persistence policy management: - -* `durability="async"` replaces `checkpoint_during=True` -* `durability="exit"` replaces `checkpoint_during=False` - -for persistence policy management, with the following mapping: - -* `checkpoint_during=True` -> `durability="async"` -* `checkpoint_during=False` -> `durability="exit"` - - -### `"exit"` - -Changes are persisted only when graph execution completes (either successfully or with an error). This provides the best performance for long-running graphs but means intermediate state is not saved, so you cannot recover from mid-execution failures or interrupt the graph execution. - -### `"async"` - -Changes are persisted asynchronously while the next step executes. This provides good performance and durability, but there's a small risk that checkpoints might not be written if the process crashes during execution. - -### `"sync"` - -Changes are persisted synchronously before the next step starts. This ensures that every checkpoint is written before continuing execution, providing high durability at the cost of some performance overhead. - -You can specify the durability mode when calling any graph execution method: +LangGraph supports three durability modes that allow you to balance performance and data consistency based on your application's requirements. A higher durability mode adds more overhead to the workflow execution. You can specify the durability mode when calling any graph execution method: :::python ```python @@ -96,6 +63,21 @@ graph.stream( ``` ::: +:::js +```typescript +graph.stream( + {"input": "test"}, + durability="sync" +) +``` +::: + +The durability modes, from least to most durable, are as follows: + +* `"exit"`: Changes are persisted only when graph execution completes (either successfully or with an error). This provides the best performance for long-running graphs but means intermediate state is not saved, so you cannot recover from mid-execution failures or interrupt the graph execution. +* `"async"`: Changes are persisted asynchronously while the next step executes. This provides good performance and durability, but there's a small risk that checkpoints might not be written if the process crashes during execution. +* `"sync"`: Changes are persisted synchronously before the next step starts. This ensures that every checkpoint is written before continuing execution, providing high durability at the cost of some performance overhead. + ## Using tasks in nodes If a [node](/oss/langgraph/graph-api#nodes) contains multiple operations, you may find it easier to convert each operation into a **task** rather than refactor the operations into individual nodes.