LangGraph JS 1.5.7 patch fixes run cancellation and stream mode handling

What changed in the run lifecycle

The update addresses several issues with how the dev server and API handle run cancellation and resource cleanup. When a stateless run is created with on_disconnect set to cancel, the request no longer leaves orphaned runs and threads if the client disconnects before completion. Previously, the server would only cancel runs that had joined with a thread ID, leaving stateless runs behind. Now when a stateless run that has not yet started is cancelled due to a dropped request, the run is deleted along with its temporary thread if no other runs remain on it. Runs configured with on_disconnect set to continue maintain their existing behavior and keep running after disconnect.

Runs that were interrupted when the dev server restarted—for example after a hot reload following a file save—now resume from their last checkpoint when the server starts again, rather than remaining stuck in a running state indefinitely. This prevents thread lockup and allows new runs to be scheduled on the same thread.

Stream mode filtering and event consistency

The dev server's run stream join endpoints now honor the stream_mode parameter, matching the behavior of the Agent Server. When a client specifies a stream mode with client.runs.joinStream(..., { streamMode }), only events matching that mode are returned; other event types are dropped. Errors always pass through regardless of mode. For messages mode, both message format types are preserved. Stream join requests that do not specify a stream_mode continue to work as before without filtering.

In messages mode, an issue where chat model replies could switch message IDs mid-stream has been fixed. Anthropic sets message IDs only on the first chunk of a reply, so the partial and complete messages could end up with mismatched IDs. Additionally, in messages mode with stream_subgraphs enabled, messages/complete is now sent for the root graph's messages, which was previously omitted.

Multitask queuing and error handling

Runs created on a busy thread that lack a multitask_strategy are now queued with the enqueue action rather than rejected with a 422 error, bringing the dev server into alignment with the Agent Server and documented API behavior.

The rollback multitask strategy has been refined to handle already-running runs more cleanly. When a run is cancelled with action set to rollback, it is now properly cancelled and deleted along with its checkpoints, allowing the next run to resume from the state before the rolled-back run. The stream now ends without an error and writes from the failed run do not persist on the thread.

Server stability and resource cleanup

Several issues that could cause the dev server's run workers to halt permanently have been resolved. Deleting a thread or run while a run is active no longer stops a worker. Failures during run completion, such as webhook URLs that cannot be reached, also no longer block workers. These fixes prevent a scenario where enough of these failures could cause the server to stop picking up new runs.

A bug in the legacy run stream with stream_subgraphs enabled has also been fixed. Nodes that stream a runnable of their own, such as a generator RunnableLambda called with the node's config, no longer fail the run with a TypeError: rawTuple is not iterable in any stream mode.

Source

AI-assisted, verified against the source. This post was drafted with AI from the primary source linked above and checked automatically against it. For anything you depend on, read the original.