Retrospective coverage for the October 30, 2026 issue.
A tool that stops to ask permission has not necessarily failed. But a progress display needs evidence before it can say “waiting for approval.” LangGraph’s tool-stream tests, at the pinned revision available for the October 30, 2026 issue, expose that distinction: an interrupted call emits a start event without an error, yet supplies no dedicated pause event in the tested sequence. That leaves an important piece of workflow meaning outside the tool-event stream.
The source tests exercise Python graphs using ToolNode and stream_mode=["tools"]. In the synchronous interrupt test, a tool calls interrupt("ok?"), with InMemorySaver configured. The initial stream contains only tool-started. Resuming through Command(resume="yes") produces another tool-started, then tool-finished, both carrying the original tool-call ID. The separate exception test expects tool-started followed by tool-error when a tool raises ValueError.
Those assertions support a narrow but useful distinction: the tested interruption is not reported as a tool error. They do not establish that every unfinished call is awaiting a person. Another test, covering a drained graph, also expects only tool-started on the tools channel. A consumer therefore cannot reliably infer “approval pending” merely from the absence of a finish or error event.
Consider a hypothetical purchasing assistant that pauses a proposed order for a manager’s authorization. Treating that pause as failure could invite an unnecessary retry; treating every unfinished call as approval-pending could conceal a different interruption. The product needs to combine tool progress with application evidence of the approval request. The repeated start with the same call ID also gives its interface a reason to preserve continuity rather than automatically present a second order attempt.
The opportunity is not a more elaborate spinner. It is an approval queue that keeps intentional waiting separate from repair work, so the manager sees the decision needing attention. These tests do not prove durable recovery, duplicate-order prevention, or production outcomes. They show why distinguishing a pause from an error is necessary—but insufficient—to make that queue trustworthy.
