mirror of
https://github.com/Comfy-Org/ComfyUI_frontend.git
synced 2026-01-30 12:59:55 +00:00
1.9 KiB
1.9 KiB
Parallel Workflow Execution - Initial Findings
Cloud PR 1743 behavior
- The PR enables parallel execution by making the per-user concurrency limit
dynamic:
DispatchConfig.MaxConcurrentJobsPerUseris added and read at runtime. - Dispatcher passes the runtime value into the state machine via
TriggerEventGloballyWithArgs, so changes apply without restart. - State machine uses the runtime limit to move jobs from
queued_limitedtoqueued_waiting, which is the gate for concurrent execution. - Environment defaults set local/ephemeral/dev to 5 and staging/prod to 1.
Key references:
common/dynamicconfig/types.goservices/dispatcher/server/services/job_dispatch/dispatcher.gocommon/jobstate/state.gocommon/dynamicconfig/defaults/ephemeral.jsoninfrastructure/dynamicconfig/prod/config.jsoninfrastructure/dynamicconfig/staging/config.jsoninfrastructure/dynamicconfig/dev/config.json
Frontend audit notes (current behavior)
- Queue fetching already supports multiple running/pending jobs via
/jobs, mapping toRunning/Pendinglists.src/platform/remote/comfyui/jobs/fetchJobs.tssrc/stores/queueStore.ts
- The concurrency indicator is based on
runningWorkflowCount, which counts prompts with running nodes and should reflect parallel execution.src/stores/executionStore.tssrc/components/queue/QueueProgressOverlay.vue
- The progress overlay is single-prompt focused:
executionStore.activePromptIdtracks one prompt.nodeProgressStatesis overwritten perprogress_state, so the progress bar and current node are effectively “last prompt wins.”src/stores/executionStore.tssrc/components/queue/QueueProgressOverlay.vue
Implication
If the frontend is expected to show per-job progress for multiple concurrent workflows, the execution store and progress overlay will need to evolve beyond the single-active-prompt assumption.