Reflex State Updates: Transitioning to Asynchronous Event Handlers for Concurrent State Modification

Reflex utilizes a reactive state-based architecture where frontend interactions trigger event handlers on a FastAPI backend via WebSockets. To prevent backend blocking during I/O-bound operations, the framework supports asynchronous event handlers (async def), allowing the event loop to remain responsive.

While async handlers prevent the server from freezing, the framework batches state changes and transmits them to the client upon the handler's completion. This creates a potential conflict when multiple concurrent WebSocket events attempt to modify the same state variable before the previous update has been fully reconciled or transmitted.

Concurrency Constraints

• State variables are modified within the Python backend.
• Updates are pushed to the client as partial UI re-renders.
• Concurrent async handlers may overlap in execution.

What is the documented behavior for resolving race conditions when two asynchronous event handlers modify the same state variable simultaneously? Does Reflex implement a locking mechanism or a specific priority queue to ensure state consistency across concurrent WebSocket events?