Tab-Graph-Prompt State Sync Issues

[christian-byrne]

After a prompt is queued from the frontend, the backend will send various messages about the status of the job.

These status messages are used for various dynamic frontend components/features, such as:

• in-node output displays (app.nodeOutputs)
• latent previews displays (app.nodePreviewImages)
• execution progress (progress bar)
• currently executing node (browser title)

The frontend workspace can have multiple tabs, each corresponding to its own graph. The frontend does not currently make an attempt to associate each prompt/job with its initiating tab/graph. As a result, the frontend defaults to assuming the status messages relate to the active graph/tab, which can be wrong (e.g., you initiate a job with tab A, then switch to tab B, then get a status message about the job after switching).

This causes various minor (for now) bugs. For this issue, a more comprehensive solution seems necessary, as it will need to be maintainable and extendable in the future.

┆Issue is synchronized with this Notion page by Unito

[christian-byrne]

Sub issues from comfyanonymous/ComfyUI (can't transfer because repos have different owner):

• Node update fails when on different tab comfyanonymous/ComfyUI#7506
• Sampling preview disappears during gen if ctrl+z is pressed or when navigating to another open workflow comfyanonymous/ComfyUI#7468
• Multiple tabs behavior? comfyanonymous/ComfyUI#7648

[QuietNoise]

Working on extension that uses the affecting and affected mechanisms and I have a chance to observe the problem up close. Backend websocket messages from PromptServer don't include information about worklow the server is currently processing (i.e. workflow id).
On front-end similarly the events are dispatched globally and consumed by nodes on whatever workflow is currently active. Other than node type, events do not include any other identifying information or option to filter out events that shouldn't be consumed.

I reckon on server side solution might be trivial by just adding workflow id to messages.
On front end it might require more serious consideration. I believe the easiest approach would be by dispatching frontend api events only when active workflow ID matched the id of the workflow from server message?

[christian-byrne]

I reckon on server side solution might be trivial by just adding workflow id to messages.

That's a good suggestion. The only hiccup might be that there could be cases where there are multiple tabs with the same workflow. We may need a new concept along the lines of "tab" or "workspace".

[QuietNoise]

Yes. Multiple browser tabs is another landmine I'm trying to wrap my head around. I.e. we can have same workflows open in multiple tabs overwriting each other when saving to the file, and when you open new tab it recreates the last workspace adding another copy of these open workflows to the "whose gona last in the saved file" race.
Multi session is always a headache for any software, justifies writing a book about it on its own 😂

P.S. The good thing is that every generated PNG is workflow's save file, so at least in this department eveyone is covered since they recover any historical version of the prompt and generated PNGs serve as is cover image :D

[nadimaj]

I had to go back to an October 2024 release in the end. I rely heavily upon multiple browser tabs to work on different workflows. I'm not interested in saving all images especially when generating large batches. If I like the look of an image in the ImagePreview window, I'd click it to expand then right click to Save. Looks like no one ever realized this beautiful way of working! and thus missed a trick with the latest UI updates :)