Python: Clarify async concurrency guarantees in WorkflowExecutor

[moonbox3]

Summary

The WorkflowExecutor stores execution contexts in a dictionary. Note: Python dicts ARE thread-safe for individual operations (due to the GIL). The real question is whether there are async race conditions - multiple coroutines interleaving at await points that could cause logical issues.

Files

File	Line
_workflow_executor.py	383

Context

# TODO check thread safety (clean up throughout ...) or declare not thread safe
self._execution_contexts[execution_id] = execution_context

Clarification needed:

1. Can two async coroutines access the same execution_id concurrently?
2. Are there compound "check-then-act" patterns that could race between await points?
3. If two writes to the same key occur, is "last write wins" acceptable?

The _execution_contexts dict is accessed when:

• Starting sub-workflow executions
• Handling response messages
• Cleaning up completed executions
• Checkpoint save/restore operations

Action Items

• Audit access patterns for async race conditions (not thread safety - dicts are already thread-safe)
• Determine if concurrent access to the same execution_id is possible
• If races exist, decide: add asyncio.Lock, or document that it is safe by design
• Update the TODO comment in code (says "thread safety" but really means async concurrency)

[moonbox3]

The old execution-context dictionary is gone. #6776 serializes calls to each executor; concurrent runs on the same workflow are rejected. Existing tests cover serialization, concurrent-run rejection, and warnings about overlapping unfinished request cycles. This resolves the original investigation without claiming arbitrary concurrent sharing is safe.