A deferred LangGraph join can run before all branches finish

An agent fans out work, joins the results and presents a confident summary. One branch is still running, so the summary is incomplete; then the join may fire again. A recent LangGraph issue reproduces early and duplicate execution when a deferred join follows a chain created with Send. This is a reported behavior in a particular version and graph shape, not a rule about every deferred node.

Reproduce the exact graph

Pin the LangGraph version and make a small graph with the same fan-out and chained branch edges. Log each node's start, completion and output key, plus the join invocation count. Test one branch, several branches and a slow branch. The LangGraph Graph API documentation explains Send and deferred execution, but the application's desired barrier still needs a test that proves all expected branch IDs arrived.

Define completion in business terms

If the join is allowed to run with partial results, label the output as partial and show what is outstanding. If it promises a complete recommendation, carry an expected set of task IDs and a completed set in state. Only assemble the final answer when the sets match. Make aggregation idempotent so a repeated join cannot double-charge, send two messages or overwrite a more complete result with an older one.

Keep the customer-facing answer honest

Exercise cancellation, retries and branch failure. Decide whether an error blocks the final answer or is represented as a missing result. A demo with three fast parallel calls may never reveal the race; the production proof is a test where one branch is deliberately delayed and the join still behaves as promised.

Adovo’s view

The visible answer should carry the same completeness guarantee as the workflow behind it. A join node is an implementation detail; the promise to the customer is that all required evidence was considered.