Symptom
Invoking a graph with Command(update=...) when the thread has no prior checkpoint applies the update twice. With an operator.add channel the report printed ['cmd', 'cmd', 'node'] instead of ['cmd', 'node'].
Evidence what you'll see
- On langgraph
1.2.16the snippet printedno checkpointer: ['cmd', 'cmd', 'node']and the same doubled list forInMemorySaverdurabilitysync,async, andexit. plain dict input:printed['cmd', 'node'].- The same doubled result appeared on main at
9e6fc45c. A comment reproduced it on main98043c37.
Why it happens
On a fresh run, _first() applies the Command as null-task writes, then passes the same Command to the START input task, which applies the update again. Pull request 9322 repaired the resumed-thread case. This is the first-run version.
Affected versions
langgraph 1.2.16, langgraph-checkpoint 4.3.0, Python 3.12.9. Also seen on main 9e6fc45c and 98043c37. Follow-up to issue #9322.
Fix steps
0 of 2 done
Your check marks stay in this browser only.
How to check it worked
- The report's snippet prints
['cmd', 'node']forCommand(update={"plain": ["cmd"]})with no checkpointer and withInMemorySaver, matching the plain dict input.
If it still fails
- A comment notes that a restricted
input_schemacan still need the early-write path so fields outside that schema stay writable, and that a directPregelworkflow may have no START extractor. - The linked issue does not name a release that applies a fresh
Command(update=...)once.
Sources and credit
Summarized in our own words from these public reports. Credit goes to their authors.
Provided as is, without warranty. Try changes in a non-production environment and back up first. Security-related steps: verify against the official docs. Terms · Request removal or attribution change
Hit an error we don't cover? Submit it