[Feature Request]: Expose progress to front end scripts

[QuietNoise]

Is there an existing issue for this?

• [x] I have searched the existing issues and checked the recent builds/commits

What would your feature do ?

Would it be possible to expose the useExecutionStore to scripts outside of comfy's build realm? Say make it a property of the app? Or perhaps there is already a way to access them stores somehow but I'm too noob to figure this out yet.

I would love to access the progress properties (i.e. totalNodesToExecute, nodesExecuted, executionProgress) without the need to rewrite the logic in that store.

Tagging you @huchenlei since you did most of the work on this.

Proposed workflow

In ideal world it would be so custom node's front-end scripts can do something like:

console.log("Progress: " + (app.executionStore.nodesExecuted / app.executionStore.totalNodesToExecute * 100) + "%";

Additional information

Alternatively, if there is a way to access the pinia stores from global space somehow then I would greatly appreciate pointing me in a right direction 🙏

[christian-byrne]

Alternatively, if there is a way to access the pinia stores from global space somehow then I would greatly appreciate pointing me in a right direction

There is a formal public API extensionManager that exposes some stores/objects:

https://github.com/Comfy-Org/ComfyUI_frontend/blob/54cd59324fba0d862e0d1760f648e118e7b66f50/src/stores/workspaceStore.ts#L73-L93

Adding things to this API technically requires that we support them and ensure they are stable long-term. It's possible that the executionStore may change significantly in the near future so it might be difficult to expose the entire store. However, the particular things you asked for could be exposed individually. It might be helpful if you elaborate a bit more on what you are building or what things in particular you want to be exposed.

Keep in mind though that the prescribed method of accessing the execution state/progress is through these websocket events.

[QuietNoise]

I’ve just started my adventure with extending ComfyUI tobenefit my own experience with the tool and give back to the community where possible. My "pet project" for now is a more robust queue management extension. I do it mainly to support my current personal needs in managing the rendering jobs and to better understand ins and outs of the backend and frontend code of the ComfyUI project.

In the long term I want to make solutions that will support multi-tenancy (i.e. managing jobs from several clients accessing the ComfyUI through API or remote instances).

As for this particular issue here I believe that having an easy access to information about total / percentage of the particular workflow progress is a basic feature that should be exposed. This would benefit any extension trying to display total workflow progress in the front end or any backend extension that would want to feed that information by, say, its own API. 

Currently only the "progress" websocket event provides numerical progress value for the node the backend is currently processing. There is no numerical value for the workflow itself though. The "executing" websocket event does not tell how many nodes were already executed. To figure out the total workflow progress one has to go through a cumbersome process of tracking items in the queue and track progress of all the nodes in a workflow (i.e. see code in the executionStore). This approach - while working - is prone to its own set of issues.

Since executionStore already does all the heavy lifting it would be great if results of that hard work were exposed for other "progress-info-hungry processes to see". Also, while writing this answer it got me thinking, that perhaps if the "executing" event could contain information like prompt_id and total_executed that would solve pretty much the most lot of the above.

As for importance, not a biggie. This does not affect critical features of the project, it's just me trying to understand limitations and structure of the cogs rotating inside.