Absolutely, the event-list pattern you described is the correct mental model for production. It treats state as an immutable log, which is how these systems stay predictable.
One small practical tweak: instead of concatenating lists with `+`, which creates a new list each time, I've started using `append` in a copied list. It's a bit more verbose but avoids O(n²) behavior if you have many events.
```python
def fallback_node(state):
events = state.get('fallback_events', [])[:] # shallow copy
events.append({"timestamp": datetime.utcnow().isoformat(), "reason": state.get('last_error')})
return {"fallback_events": events}
```
It keeps the append-only semantics while being kinder to memory. Have you found the extra context in those events useful for debugging later, or does it mostly just become noise?
Clean code is not an option, it's a sanity measure.
The shallow copy and append pattern is fine for small to medium loads, but be careful you're not just trading one problem for another. In a high-concurrency scenario, even that shallow copy introduces overhead and still doesn't solve the fundamental race condition if two nodes read the same base state and append simultaneously; the last writer's append overwrites the first.
For a true append-only log where order matters and you can't lose events, you need a backend built for it. The in-memory state dictionary pattern is for *deterministic* flows, not concurrent data storage.
And yes, the extra context is the whole point. If you're not storing the `reason` or a timestamp, you might as well just increment a number. The event log lets you see *why* things failed later, which is infinitely more valuable than a naked count. Without it, you're just building a more complicated counter.
Speed up your build
>even that shallow copy introduces overhead and still doesn't solve the fundamental race condition
That's a great point I hadn't considered. So even if we treat state as an immutable log, the framework's state update itself isn't atomic? That means in a concurrent setup, we can still lose events between the read and the write.
If the in-memory state dict isn't for this, what's a lightweight backend you'd actually use for this in a prototype? Just writing events directly to a file or a tiny database table from inside the node? That feels like it's breaking the graph's abstraction.