dots-event-driven-ecs

To handle one-frame events in Unity DOTS ECS safely, model them as explicit data using request entities via ECB, enableable command components, or event buffers with deterministic lifetime and late-phase cleanup to prevent persistent state leaks.

The best way to model external input and network requests in Unity ECS is using request entities or enableable command components, ensuring deterministic producer/consumer ownership and exactly-one consumption without structural changes.

ECS event buffers cause double-application or missed consumption in Burst when using managed-world patterns like C# events or static buses, or when ECB phase ordering is wrong and request entities are not destroyed properly.

Refactor an ECS gameplay flow by converting every one-frame UI or input trigger into an enableable command component or request entity, defining a clear single consumer and a guaranteed clearing or destroy step to satisfy Entities 1.x requirements.

You should not use managed event buses for Unity DOTS gameplay triggers when you need Burst-safe, replay-safe execution, as they bypass deterministic lifetime management, cause dual ownership issues, and prevent reliable clearing and destroy verification.