get_images() hangs unless UI open in browser

[Terristen]

I'm having trouble with the websocket API. Specifically, calls to the API run up to the end of the first sampler, but then hang and do not respond to the ws.recv() in get_images(). If the browser UI is open in an active tab, on any workflow whatsoever, the hang doesn't happen... the workflow completes as expected. Keep in mind, the UI doesn't have to be showing the workflow being prompted, but it does have to be in an active browser tab.

If the interface is not open anywhere, or if the interface is on a hidden tab, the API call will hang.

My theory is that the browser interface is pinging the server somehow and allowing the graph to continue executing; but I cannot figure out what it is doing.

My app is a Quart web-app and my code is all contained within a blueprint specifically for the image generation. There's an async route that handles the request, then it generates the prompt, and at that point relies on the example API code.

The weird thing is that this happens on two different workflows, but I don't recall it happening prior to yesterday (Jul 21). I am using rgthree's patch, and turning off the patch doesn't change the behavior.

I had read that some people had issues because they were creating a new websocket instance with every request. I checked for that, and am now caching the ws object for reuse, so I don't think it's the same problem.

I'm using a basic KSampler and ReActor detailers, so it's not like I'm using untested nodes. I am not saving the generated images, only using preview nodes to keep server file-bloat from happening.

At this point I'm wondering two things:

1. Can I use straight http requests and bypass the WS altogether?
2. Would wrapping these ws calls in a ThreadPoolExecutor be beneficial? or have any affect on this issue?

I appreciate any insight the community has on this issue. I'd share code examples, except that my latest code isn't pushed to github yet and I'm not at my home workstation. I apologize in advance for that.

[Terristen]

Update: Still having this issue.

• I converted all the functions from the example to an asynchronous websocket implementation. -still hanging
• I rewrote the get_images() function a couple times. -still hanging
• Stopped short of wrapping everything in a ThreadPoolExecutor.
• Modified the workflow to simplify. -still hanging
• updated all custom nodes and comfyui. -still hanging
• Added debugging outputs of the result of recv() -still hanging, but with lots of console spam

I will say that the debugging data is interesting, but without a decoder ring to grok the data with regard to normal operations, I'm in the dark still.

I thought that maybe the (While True) loop might be locking up everything by maybe getting a result it didn't expect, but if I open the UI, it carries on like a trooper when ComfyUI starts churning again.

From memory (sorry, not at home atm) the log output gets something like the following:
execute
execute
execute
progress 1of 20
progress 2of 20
progress 3of 20
...
progress 20 of 20
---freezes here---

It seems that if I open the UI for a moment, it starts again... then after the next progress x of y completion, freezes again.

[wangmouren609]

Is this issue still present now?