Possible Event Loss / Misordered `executing` Events When History Grows Large

[zhzLuke96]

During recent stress testing against the latest versions of ComfyUI, I encountered a subtle but critical issue that appears to be related to history list growth and event dispatching.

Observed Behavior

When continuously calling enqueue using the same client_id (i.e. the same WebSocket client) for a prolonged period:

• After reaching an internal threshold, ComfyUI stops emitting executing events, or
• executing events are emitted with incorrect timing / ordering

As a result:

• The client can no longer reliably determine which task a given image_data event belongs to
• This causes incorrect task–output association
• In my case, this breaks higher-level abstractions such as InvokedWorkflow, which relies on executing events to track task state

This issue is hard to reproduce in small tests but becomes consistent under sustained enqueue pressure.

Hypothesis

The issue seems correlated with:

• A large /history list
• Multiple tasks queued under the same client_id
• WebSocket event dispatch possibly depending on history indexing or traversal

This suggests a potential internal coupling between history management and WS event emission.

Workarounds (Confirmed Effective)

Currently, the following mitigations work reliably:

1. Use a fresh Client (new client_id) per request
   This avoids task accumulation under a single WebSocket connection.

2. Explicitly clear history after each task completes

   await client.clearItems("history");

   Surprisingly:

   • This significantly improves stability
   • It also improves generation performance
   • It is more effective than calling client.free() for memory-related slowdowns

Impact on Libraries

For client libraries (such as mine) that:

• Aggregate WS events
• Correlate executing → progress → image_data
• Provide synchronous or promise-based APIs

This issue makes it impossible to guarantee correctness without heavy client-side isolation or aggressive history cleanup.

Current Status

At the moment, I don’t see a clean client-side solution that fully resolves this.

The problem likely requires:

• Changes in ComfyUI’s history management
• Or a more explicit task-scoped event model on the WebSocket layer

If I find time, I plan to dig into ComfyUI’s server-side code to locate the root cause.

If others have encountered similar behavior or have insights into the event dispatch mechanism, I’d appreciate any pointers.