After updating the latest version, a BUG will appear in the prompt queue.

[davidchenhs]

I spent two nights reinstalling the nodes and dependencies, and finally found out that it was a version update problem, which caused a bug in the queue. Under the condition that it is automatically executed when the status changes, dragging the mouse or other operations will also be executed.

[davidchenhs]

This is after I reinstalled the old version of the UI. No matter what I did, its queue number would not change, while the new version would be forced to do so due to various factors, causing the queue to keep increasing. This is what I get after updating the version

[ltdrdata]

see the browser log

[davidchenhs]

Is it this one?

[ltdrdata]

Is it this one?

what about console?

[davidchenhs]

This is an updated version. It seems that the problem occurs in the security scan. This problem seems to have occurred since this thing was introduced.

[ltdrdata]

This is an updated version. It seems that the problem occurs in the security scan. This problem seems to have occurred since this thing was introduced.

Security scan is irrelevant. It cannot affect to anything after launch. Disable rgthree and try again.

[davidchenhs]

It has nothing to do with rgthree

[ltdrdata]

Author

That message doesn't meaning anything. Just prompt is passed. That's all. It doesn't mean execute again. Just the weired part is the queue items in browser.

So I told you check the browser log. like this.

It seems that something is preventing clearing of the items in queue in frontend.

[davidchenhs]

[davidchenhs]

I finally found the update date that caused the problem. The ones that were checked indicated that this problem occurred after updating to this version. The ones that were not checked meant that there was no problem.

[shawnington]

I have no idea how commit f374ea7 would cause this issue, unless it somehow introduced a namespace conflict that causes unexpected behavior downstream. What browser is being used?

[rgthree]

I've looked into this since @davidchenhs originally filed a bug in rgthree-comfy. Looking into it, they're correct that f374ea7 introduces unintended behavior that causes auto-queue to fire while just dragging the canvas (whereas before that, it did not).

• This is due to f374ea7 changing the workflow data that's returned from LGraph.prototype.serialize in the workflow.extra field.
• In extensions/core/undoRedo.js there's a checkState function that checks the return value every time LGraph.prototype.serialize is invoked to see if it's changed so it can add to the undo stack and, if it has, then fires a graphChanged event.
• This event is also listened to in web/scripts/ui.js and queues a prompt when enabled (and the queue size is 0).

If this was not intended, then either that checkState function should not consider the new fields as data to add to the undo stack, OR, there should be a better event fired only when the actual workflow being sent to the server is changed (instead of just positioning).

(Note, even before f374ea7 autoqueue would fire when moving a node and, arguable, that's not necessary).

[rgthree]

With all that said, I'm curious, @davidchenhs, what issue this really causes and if there's more to this than I see. If the prompt hasn't changed, no real work is being done even if its sent to the server. It's not much more than a simple ping-pong.

Perhaps it was just the log messages that appear (rgthree-comfy, timing, etc) that appear over and over?

[davidchenhs]

Under complex workflow conditions, if I add a prompt queue, the queue will be repeated many times. Not only the log will be repeated, but the loading of the nodes inside will also be repeated. For example, if I use a node that plays sound, when After I add the prompt queue, it will keep making sounds

[davidchenhs]

我不知道提交f374ea7会如何导致此问题，除非它以某种方式引入了命名空间冲突，从而导致下游出现意外行为。 正在使用哪种浏览器？

Chrome

[davidchenhs]

I finally found the update date that caused the problem. The ones that were checked indicated that this problem occurred after updating to this version. The ones that were not checked meant that there was no problem.

I found that switching versions can improve the automatic execution of the drag interface, but if there is rgthree's image compare node, there will be a situation where the parameters are adjusted once and then the queue is loaded all the time. I finally changed back to the 0fecfd2 version and disabled rgthree's image compare node. The method perfectly solved the problem. @rgthree @shawnington @ltdrdata