builders · review · first seen Oct 27, 09:33 UTC

LangGraph changes snapshots and fixes runtime, SDK and CLI behavior

LangGraph 1.2.18 shipped a shorter DeltaChannel snapshot interval and fixes for recovery and stopped-run streams. SDK 0.4.10 shipped SSE parsing fixes. Builders should check storage and stream handling before upgrading.

L0 · primary1 source4 claims checked4 min read

What shipped

LangGraph 1.2.18 changed DeltaChannel's default full-snapshot interval from 1000 updates to 100. The release notes describe the tradeoff directly: faster reads on long threads, with more storage. Passing snapshot_frequency=1000 keeps the previous interval. If your application uses DeltaChannel and depends on its old storage profile, that setting is the immediate control to inspect. [1]

The same release shipped a fix allowing error_handler to recover on every path and a fix that streams the last checkpoint when a run stops at interrupt_after or the recursion limit. The notes also say the error-handling change streams failed task results. These are distinct behaviors: one concerns recovery from errors, while the other concerns what a consumer receives when a run stops. Neither is described as changing the condition that causes a stop. [1][2]

LangGraph SDK 0.4.10 shipped SSE handling for multi-line data, empty IDs and a leading BOM. Its release notes also list a runs.wait retry with a bodyless GET, raising run errors in sync wait, and acceptance of durability, stream_resumable and context in runs overloads. Those are additional regression targets, but the traced SDK claim here is the SSE fix. The supplied CLI 0.4.39 excerpt separately lists --json for deploy list; it does not establish that the runtime or SDK fixes are CLI changes. [1]

Why it matters if you build

For a builder keeping long DeltaChannel threads, the changed snapshot cadence shifts an operating choice. More frequent full snapshots can make reads faster while increasing storage, according to the release notes. Compare read behavior and stored checkpoint footprint under your own workload before treating the new default as an improvement. If storage matters more than the stated read benefit, try snapshot_frequency=1000 to preserve the old interval. The supplied material gives no measured latency or storage difference, so a local comparison should drive the decision. [1]

If your workflow resumes from errors or consumes streamed state when a run stops, the runtime fixes change what you can inspect. Exercise an error_handler recovery path and inspect failed task results in the stream. Then stop a run with interrupt_after and another at the recursion limit, and check whether each stream includes its last checkpoint. The notes identify those outcomes, but do not specify an application-level retry policy or guarantee that a stopped run completed its intended work. Keep those decisions in your own control flow. [1][2]

For clients that parse SSE, test an event with multi-line data, an empty ID and a leading BOM against SDK 0.4.10. These are concrete compatibility cases, not a claim that all streaming failures are resolved. If your integration uses runs.wait or the named runs overload arguments, the same SDK excerpt gives additional regression targets. Check the CLI deploy-list JSON option separately if your tooling consumes that command; the supplied claims do not establish that it affects SDK event parsing. [1]

How to try it today

1. Record the current DeltaChannel snapshot_frequency setting. Compare the 100-update default with snapshot_frequency=1000 on a representative long thread.
2. Run a case that enters error_handler; check recovery and whether failed task results appear in the stream.
3. Stop runs at interrupt_after and the recursion limit; inspect the last checkpoint in each stream.
4. Feed SDK 0.4.10 SSE events with multi-line data, empty IDs and a leading BOM through your consumer.
5. Decide separately whether the snapshot storage tradeoff and the stream changes warrant an upgrade in your application.

What we checked

Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.

1. shipped L0 · primary

   LangGraph 1.2.18 changes DeltaChannel's default full-snapshot interval from 1000 updates to 100 updates.

   per GitHub releases · langchain-ai/langgraph (L0); contradicted by GitHub releases · langchain-ai/langgraph (L0); contradicted by GitHub releases · langchain-ai/langgraph (L0); contradicted by GitHub releases · langchain-ai/langgraph (L0)
2. shipped L0 · primary

   LangGraph 1.2.18 lets error_handler recover on every path.

   per GitHub releases · langchain-ai/langgraph (L0); contradicted by GitHub releases · langchain-ai/langgraph (L0); contradicted by GitHub releases · langchain-ai/langgraph (L0); contradicted by GitHub releases · langchain-ai/langgraph (L0)
3. shipped L0 · primary

   LangGraph 1.2.18 streams the last checkpoint when a run stops at interrupt_after or the recursion limit.

   per GitHub releases · langchain-ai/langgraph (L0); contradicted by GitHub releases · langchain-ai/langgraph (L0); contradicted by GitHub releases · langchain-ai/langgraph (L0); contradicted by GitHub releases · langchain-ai/langgraph (L0)
4. shipped L0 · primary

   LangGraph SDK 0.4.10 fixes SSE handling for multi-line data, empty IDs and a leading BOM.

   per GitHub releases · langchain-ai/langgraph (L0); contradicted by GitHub releases · langchain-ai/langgraph (L0); contradicted by GitHub releases · langchain-ai/langgraph (L0); contradicted by GitHub releases · langchain-ai/langgraph (L0); contradicted by GitHub releases · langchain-ai/langgraph (L0)

What is not confirmed

The supplied notes do not quantify read latency, storage growth or the workload at which a 100-update interval is preferable. They do not establish that every error becomes recoverable, that a stopped run finishes successfully, or that the SDK handles every SSE edge case. The CLI excerpt lists a deploy-list option, but the traced claims do not establish a CLI dependency for these runtime and SDK fixes. Test those boundaries rather than treating a release-note fix as a broad operational guarantee. [1][2][3][4]

Who should act, who should wait

Move now to evaluation if you operate long DeltaChannel threads, depend on error recovery or stopped-run checkpoint streams, or parse SSE with the named edge cases. Test the relevant package versions against the behavior your application consumes; retain snapshot_frequency=1000 if the former interval better fits your storage budget. Wait on a rollout if you cannot yet measure the storage effect or exercise your recovery and streaming paths. The notes give a reason to test these releases, not evidence that every deployment will benefit. [1][2][3][4]

Sources

• langgraph-cli==0.4.39 — GitHub releases · langchain-ai/langgraph L0 · primary
• langgraph-cli==0.4.40 — GitHub releases · langchain-ai/langgraph L0 · primary
• langgraph-checkpoint==4.3.1 — GitHub releases · langchain-ai/langgraph L0 · primary
• langgraph-sdk==0.4.10 — GitHub releases · langchain-ai/langgraph L0 · primary
• langgraph==1.2.18 — GitHub releases · langchain-ai/langgraph L0 · primary