A parallel plan crashed the scaffold: shared fields become reducers

[Shashankss1205]

The defect

The grapharc init scaffold and the shipped incident example both declared their shared working field as a plain list:

notes: list[str] = [] # scaffold State, and IncidentState

with every body appending by hand ({"notes": [*state.notes, note]}). That works only while no two writers land in the same superstep. The first time a planner fans two kinds out of START, or instantiates one kind twice in parallel branches, LangGraph refuses the concurrent update:

InvalidUpdateError: At key 'notes': Can receive only one value per step.

This is not hypothetical: a local qwen3:8b, asked to investigate two hypotheses in parallel, proposed a 16-node dual-branch graph that instantiated pull_deploys once per branch, and the run died mid-execution after admission had already said yes. The gate approved a graph the state contract could not execute.

The fix

The shared field becomes a reducer in both places, and writers return only their own lines:

notes: Annotated[list[str], operator.add] = []
...
return {"notes": [note]}

Parallel writers now merge instead of colliding, sequential behavior is byte-identical (the scaffold's scripted refuse-then-admit first run still prints the same lines), and the scaffold's comment explains the rule to registry authors: any field more than one node may write needs a reducer, because a planner will eventually run two writers in one step.

Tests

• test_the_scaffold_state_merges_parallel_writers (tests/test_cli.py): executes the actual REGISTRY_TEMPLATE with a scripted plan that fans gather and analyse out of START; asserts goal_met with both notes present. This run raised InvalidUpdateError before the fix.
• test_the_incident_example_state_merges_parallel_writers (tests/test_planner_loop.py): three kinds writing notes in one superstep through plan_incident.build_loop; asserts all three lines land.
• Full suite: 1,987 passed, 12 deselected; ruff clean.

grapharc/stdlib.py already used reducers and is untouched; this brings the two remaining shipped states up to the same discipline.

🤖 Generated with Claude Code

[Shashankss1205]

The defect

The grapharc init scaffold and the shipped incident example both declared their shared working field as a plain list:

notes: list[str] = [] # scaffold State, and IncidentState

with every body appending by hand ({"notes": [*state.notes, note]}). That works only while no two writers land in the same superstep. The first time a planner fans two kinds out of START, or instantiates one kind twice in parallel branches, LangGraph refuses the concurrent update:

InvalidUpdateError: At key 'notes': Can receive only one value per step.

This is not hypothetical: a local qwen3:8b, asked to investigate two hypotheses in parallel, proposed a 16-node dual-branch graph that instantiated pull_deploys once per branch, and the run died mid-execution after admission had already said yes. The gate approved a graph the state contract could not execute.

The fix

The shared field becomes a reducer in both places, and writers return only their own lines:

notes: Annotated[list[str], operator.add] = []
...
return {"notes": [note]}

Parallel writers now merge instead of colliding, sequential behavior is byte-identical (the scaffold's scripted refuse-then-admit first run still prints the same lines), and the scaffold's comment explains the rule to registry authors: any field more than one node may write needs a reducer, because a planner will eventually run two writers in one step.

Tests

• test_the_scaffold_state_merges_parallel_writers (tests/test_cli.py): executes the actual REGISTRY_TEMPLATE with a scripted plan that fans gather and analyse out of START; asserts goal_met with both notes present. This run raised InvalidUpdateError before the fix.
• test_the_incident_example_state_merges_parallel_writers (tests/test_planner_loop.py): three kinds writing notes in one superstep through plan_incident.build_loop; asserts all three lines land.
• Full suite: 1,987 passed, 12 deselected; ruff clean.

grapharc/stdlib.py already used reducers and is untouched; this brings the two remaining shipped states up to the same discipline.

🤖 Generated with Claude Code

[Shashankss1205]

The defect

The grapharc init scaffold and the shipped incident example both declared their shared working field as a plain list:

notes: list[str] = [] # scaffold State, and IncidentState

with every body appending by hand ({"notes": [*state.notes, note]}). That works only while no two writers land in the same superstep. The first time a planner fans two kinds out of START, or instantiates one kind twice in parallel branches, LangGraph refuses the concurrent update:

InvalidUpdateError: At key 'notes': Can receive only one value per step.

This is not hypothetical: a local qwen3:8b, asked to investigate two hypotheses in parallel, proposed a 16-node dual-branch graph that instantiated pull_deploys once per branch, and the run died mid-execution after admission had already said yes. The gate approved a graph the state contract could not execute.

The fix

The shared field becomes a reducer in both places, and writers return only their own lines:

notes: Annotated[list[str], operator.add] = []
...
return {"notes": [note]}

Parallel writers now merge instead of colliding, sequential behavior is byte-identical (the scaffold's scripted refuse-then-admit first run still prints the same lines), and the scaffold's comment explains the rule to registry authors: any field more than one node may write needs a reducer, because a planner will eventually run two writers in one step.

Tests

• test_the_scaffold_state_merges_parallel_writers (tests/test_cli.py): executes the actual REGISTRY_TEMPLATE with a scripted plan that fans gather and analyse out of START; asserts goal_met with both notes present. This run raised InvalidUpdateError before the fix.
• test_the_incident_example_state_merges_parallel_writers (tests/test_planner_loop.py): three kinds writing notes in one superstep through plan_incident.build_loop; asserts all three lines land.
• Full suite: 1,987 passed, 12 deselected; ruff clean.

grapharc/stdlib.py already used reducers and is untouched; this brings the two remaining shipped states up to the same discipline.

🤖 Generated with Claude Code

[Shashankss1205]

The defect

The grapharc init scaffold and the shipped incident example both declared their shared working field as a plain list:

notes: list[str] = [] # scaffold State, and IncidentState

with every body appending by hand ({"notes": [*state.notes, note]}). That works only while no two writers land in the same superstep. The first time a planner fans two kinds out of START, or instantiates one kind twice in parallel branches, LangGraph refuses the concurrent update:

InvalidUpdateError: At key 'notes': Can receive only one value per step.

This is not hypothetical: a local qwen3:8b, asked to investigate two hypotheses in parallel, proposed a 16-node dual-branch graph that instantiated pull_deploys once per branch, and the run died mid-execution after admission had already said yes. The gate approved a graph the state contract could not execute.

The fix

The shared field becomes a reducer in both places, and writers return only their own lines:

notes: Annotated[list[str], operator.add] = []
...
return {"notes": [note]}

Parallel writers now merge instead of colliding, sequential behavior is byte-identical (the scaffold's scripted refuse-then-admit first run still prints the same lines), and the scaffold's comment explains the rule to registry authors: any field more than one node may write needs a reducer, because a planner will eventually run two writers in one step.

Tests

• test_the_scaffold_state_merges_parallel_writers (tests/test_cli.py): executes the actual REGISTRY_TEMPLATE with a scripted plan that fans gather and analyse out of START; asserts goal_met with both notes present. This run raised InvalidUpdateError before the fix.
• test_the_incident_example_state_merges_parallel_writers (tests/test_planner_loop.py): three kinds writing notes in one superstep through plan_incident.build_loop; asserts all three lines land.
• Full suite: 1,987 passed, 12 deselected; ruff clean.

grapharc/stdlib.py already used reducers and is untouched; this brings the two remaining shipped states up to the same discipline.

🤖 Generated with Claude Code

[Shashankss1205]

The defect

The grapharc init scaffold and the shipped incident example both declared their shared working field as a plain list:

notes: list[str] = [] # scaffold State, and IncidentState

with every body appending by hand ({"notes": [*state.notes, note]}). That works only while no two writers land in the same superstep. The first time a planner fans two kinds out of START, or instantiates one kind twice in parallel branches, LangGraph refuses the concurrent update:

InvalidUpdateError: At key 'notes': Can receive only one value per step.

This is not hypothetical: a local qwen3:8b, asked to investigate two hypotheses in parallel, proposed a 16-node dual-branch graph that instantiated pull_deploys once per branch, and the run died mid-execution after admission had already said yes. The gate approved a graph the state contract could not execute.

The fix

The shared field becomes a reducer in both places, and writers return only their own lines:

notes: Annotated[list[str], operator.add] = []
...
return {"notes": [note]}

Parallel writers now merge instead of colliding, sequential behavior is byte-identical (the scaffold's scripted refuse-then-admit first run still prints the same lines), and the scaffold's comment explains the rule to registry authors: any field more than one node may write needs a reducer, because a planner will eventually run two writers in one step.

Tests

• test_the_scaffold_state_merges_parallel_writers (tests/test_cli.py): executes the actual REGISTRY_TEMPLATE with a scripted plan that fans gather and analyse out of START; asserts goal_met with both notes present. This run raised InvalidUpdateError before the fix.
• test_the_incident_example_state_merges_parallel_writers (tests/test_planner_loop.py): three kinds writing notes in one superstep through plan_incident.build_loop; asserts all three lines land.
• Full suite: 1,987 passed, 12 deselected; ruff clean.

grapharc/stdlib.py already used reducers and is untouched; this brings the two remaining shipped states up to the same discipline.

🤖 Generated with Claude Code

[Shashankss1205]

The defect

The grapharc init scaffold and the shipped incident example both declared their shared working field as a plain list:

notes: list[str] = [] # scaffold State, and IncidentState

with every body appending by hand ({"notes": [*state.notes, note]}). That works only while no two writers land in the same superstep. The first time a planner fans two kinds out of START, or instantiates one kind twice in parallel branches, LangGraph refuses the concurrent update:

InvalidUpdateError: At key 'notes': Can receive only one value per step.

This is not hypothetical: a local qwen3:8b, asked to investigate two hypotheses in parallel, proposed a 16-node dual-branch graph that instantiated pull_deploys once per branch, and the run died mid-execution after admission had already said yes. The gate approved a graph the state contract could not execute.

The fix

The shared field becomes a reducer in both places, and writers return only their own lines:

notes: Annotated[list[str], operator.add] = []
...
return {"notes": [note]}

Parallel writers now merge instead of colliding, sequential behavior is byte-identical (the scaffold's scripted refuse-then-admit first run still prints the same lines), and the scaffold's comment explains the rule to registry authors: any field more than one node may write needs a reducer, because a planner will eventually run two writers in one step.

Tests

• test_the_scaffold_state_merges_parallel_writers (tests/test_cli.py): executes the actual REGISTRY_TEMPLATE with a scripted plan that fans gather and analyse out of START; asserts goal_met with both notes present. This run raised InvalidUpdateError before the fix.
• test_the_incident_example_state_merges_parallel_writers (tests/test_planner_loop.py): three kinds writing notes in one superstep through plan_incident.build_loop; asserts all three lines land.
• Full suite: 1,987 passed, 12 deselected; ruff clean.

grapharc/stdlib.py already used reducers and is untouched; this brings the two remaining shipped states up to the same discipline.

🤖 Generated with Claude Code

[Shashankss1205]

The defect

The grapharc init scaffold and the shipped incident example both declared their shared working field as a plain list:

notes: list[str] = [] # scaffold State, and IncidentState

with every body appending by hand ({"notes": [*state.notes, note]}). That works only while no two writers land in the same superstep. The first time a planner fans two kinds out of START, or instantiates one kind twice in parallel branches, LangGraph refuses the concurrent update:

InvalidUpdateError: At key 'notes': Can receive only one value per step.

This is not hypothetical: a local qwen3:8b, asked to investigate two hypotheses in parallel, proposed a 16-node dual-branch graph that instantiated pull_deploys once per branch, and the run died mid-execution after admission had already said yes. The gate approved a graph the state contract could not execute.

The fix

The shared field becomes a reducer in both places, and writers return only their own lines:

notes: Annotated[list[str], operator.add] = []
...
return {"notes": [note]}

Parallel writers now merge instead of colliding, sequential behavior is byte-identical (the scaffold's scripted refuse-then-admit first run still prints the same lines), and the scaffold's comment explains the rule to registry authors: any field more than one node may write needs a reducer, because a planner will eventually run two writers in one step.

Tests

• test_the_scaffold_state_merges_parallel_writers (tests/test_cli.py): executes the actual REGISTRY_TEMPLATE with a scripted plan that fans gather and analyse out of START; asserts goal_met with both notes present. This run raised InvalidUpdateError before the fix.
• test_the_incident_example_state_merges_parallel_writers (tests/test_planner_loop.py): three kinds writing notes in one superstep through plan_incident.build_loop; asserts all three lines land.
• Full suite: 1,987 passed, 12 deselected; ruff clean.

grapharc/stdlib.py already used reducers and is untouched; this brings the two remaining shipped states up to the same discipline.

🤖 Generated with Claude Code

[Shashankss1205]

The defect

The grapharc init scaffold and the shipped incident example both declared their shared working field as a plain list:

notes: list[str] = [] # scaffold State, and IncidentState

with every body appending by hand ({"notes": [*state.notes, note]}). That works only while no two writers land in the same superstep. The first time a planner fans two kinds out of START, or instantiates one kind twice in parallel branches, LangGraph refuses the concurrent update:

InvalidUpdateError: At key 'notes': Can receive only one value per step.

This is not hypothetical: a local qwen3:8b, asked to investigate two hypotheses in parallel, proposed a 16-node dual-branch graph that instantiated pull_deploys once per branch, and the run died mid-execution after admission had already said yes. The gate approved a graph the state contract could not execute.

The fix

The shared field becomes a reducer in both places, and writers return only their own lines:

notes: Annotated[list[str], operator.add] = []
...
return {"notes": [note]}

Parallel writers now merge instead of colliding, sequential behavior is byte-identical (the scaffold's scripted refuse-then-admit first run still prints the same lines), and the scaffold's comment explains the rule to registry authors: any field more than one node may write needs a reducer, because a planner will eventually run two writers in one step.

Tests

• test_the_scaffold_state_merges_parallel_writers (tests/test_cli.py): executes the actual REGISTRY_TEMPLATE with a scripted plan that fans gather and analyse out of START; asserts goal_met with both notes present. This run raised InvalidUpdateError before the fix.
• test_the_incident_example_state_merges_parallel_writers (tests/test_planner_loop.py): three kinds writing notes in one superstep through plan_incident.build_loop; asserts all three lines land.
• Full suite: 1,987 passed, 12 deselected; ruff clean.

grapharc/stdlib.py already used reducers and is untouched; this brings the two remaining shipped states up to the same discipline.

🤖 Generated with Claude Code