LangGraph event streaming can duplicate reducer state

A LangGraph issue reports that astream_events can ignore a subgraph's output_schema. In the reproduction, the subgraph should return only its written text field, while a parent reducer collects results. The event-stream path takes input state back into the parent and duplicates reducer data without throwing an error. This is more insidious than a crash: a downstream summary can be wrong while the run is marked successful.

Compare execution paths with the same input

Build a small graph with a fan-out, a reducer channel, and a subgraph whose output schema excludes that channel. Run it once with ordinary invocation and once through astream_events, then compare final state, not only streamed events. Capture graph and package versions. The issue's reproduction provides a narrow test; adapt it before generalizing to a production graph.

Protect the business output

If reducer state feeds citations, totals, or action counts, validate invariants before rendering or committing results. For example, compare unique item identifiers with expected fan-out work and flag duplicates. Do not deduplicate blindly: two legitimate results can have identical text. Trace each contribution to a task ID and subgraph boundary so the correction preserves real repeats.

Use a release gate for streaming changes

Pin a known-good execution path for critical results while testing candidate fixes. A streaming UI can still show progress, but the final authoritative state needs a test against expected output. Add the regression case to the deployment suite and record whether the defect is specific to the reported version and topology.

Adovo’s view

A successful run is not a correct answer. When state crosses a graph boundary, the output schema must be tested as a data contract, especially where reducers can silently magnify an error.