Applied AI
LangGraph resume can return before child fan-out completes
Detect incomplete LangGraph child output after a sibling failure and checkpoint resume.
October 29, 2026
A parent LangGraph run has a child graph that fans out work with Send, while a sibling node fails once. After checkpoint resume, the child may return only the state from its first step, without the fan-out or reducer output. The open issue and runnable reproduction reports this on 1.2.18 when both a node TimeoutPolicy and child step_timeout are set, even though neither timeout fires. That narrow condition matters; it is not a claim about all graph resumes.
Define completion as a business invariant
If a child graph should produce three parts and a combined result, validate the parts count, expected keys, and final result before a parent node accepts success. Treat a missing total as a failure to investigate, not a string to pass downstream. The example returns partial state without an exception, so monitoring only thrown errors would miss it. Use run IDs and checkpoint state to relate the first failure to the resumed output.
Test the exact recovery path
Build a small test graph mirroring the parent, child, fan-out, timeout settings, and sibling failure. Execute one failed run, resume the same thread, and assert the final child output. The LangGraph durable-execution guide explains checkpointed recovery; it does not certify that every combination of policies has the expected behavior. Keep the test tied to your installed version and rerun it on upgrade.
Choose a bounded operational response
If your graph matches the reproduction, isolate the job class and require output validation before side effects. The issue shows that removing either timeout changes its test result, but changing timeouts in production has its own failure-mode costs. Evaluate that tradeoff in a staging copy; do not remove guardrails globally based on one report. Track the upstream issue for a supported fix and retain a replay path for affected jobs.
Adovo’s view
An agent workflow is complete only when its intended work is complete. A returned state is not proof. Put the acceptance condition at the business boundary, especially after retries and resumes where partial progress can look plausible.
