mirror of
https://github.com/comfyanonymous/ComfyUI.git
synced 2026-05-06 15:22:31 +08:00
2205341279
The frontend already stores extra_data['extra_pnginfo']['workflow']['id'] when queueing a prompt and exposes it via the /api/jobs REST endpoint, but none of the WebSocket events emitted during execution carry it. That makes it impossible to scope progress state by workflow on the client without maintaining a job_id -> workflow_id mapping that races with execution_start. This adds workflow_id alongside prompt_id on every execution event: - execution_start, execution_success, execution_error, execution_interrupted, execution_cached, executing, executed - progress and progress_state - the metadata block on PREVIEW_IMAGE_WITH_METADATA A new public extract_workflow_id helper in comfy_execution/jobs.py is the single source of truth for the lookup; the existing _extract_job_metadata delegates to it. The id is plumbed through PromptExecutor (stored as self.workflow_id and on server.last_workflow_id), the module-level execute() coroutine, the _send_cached_ui helper, and ProgressRegistry / reset_progress_state so WebUIProgressHandler can include it in progress_state and preview-image metadata. The progress hook in main.py reads server.last_workflow_id to populate the legacy 'progress' event. Tests cover the helper's edge cases (missing/non-string ids, non-dict levels) and that the WebUIProgressHandler emits workflow_id on every progress_state payload via mocked PromptServer. |
||
|---|---|---|
| .. | ||
| cache_provider.py | ||
| caching.py | ||
| graph_utils.py | ||
| graph.py | ||
| jobs.py | ||
| progress.py | ||
| utils.py | ||
| validation.py | ||