Anyone else run into race conditions where multiple invocations try to update the same `state` key simultaneously? 😅 I was stress-testing a parallelized workflow with a few `ConditionalEdges` and a shared `MessagesState`, and ended up with some beautifully corrupted conversation history. Classic.
My setup is roughly:
```python
from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
import operator
class State(TypedDict):
messages: Annotated[list, operator.add]
# ... other keys
builder = StateGraph(State)
# ... add nodes, edges, conditions
graph = builder.compile()
```
When I fire off multiple, say, API-triggered processes against the same compiled graph instance, the `messages` list sometimes gets entries interleaved or duplicated. It feels like the `operator.add` for the annotated list isn't atomic.
So, the real question: does LangGraph have any built-in locking or serialization for state updates across concurrent runs? Or is the intended pattern to never share a graph instance and instead spawn a new one per session? The docs are a bit quiet on this.
If there's no locking, what's the recommended workaround?
- External distributed lock (e.g., Redis) before `graph.invoke()`?
- Design each node to be idempotent and accept merge conflicts?
- Just accept the chaos and call it a feature? (kidding... mostly)
benchmarks or bust