WIP

plan.md

@@ -0,0 +1,107 @@
+# Parallel Execution Implementation Plan
+
+## Goals
+- Support multiple simultaneous workflow executions across:
+  - Separate browser tabs (multiple clients).
+  - In-app workflow tabs (multiple workflows).
+- Show correct progress, outputs, and errors per workflow/job.
+- Avoid regressions for single-run behavior and existing UI.
+
+## Non-goals (initial scope)
+- Redesign the queue UI beyond enabling per-job progress indicators.
+- New backend features beyond prompt context for WS events (see dependencies).
+
+## Dependencies / coordination (verified vs `../cloud-3` + `../backend-3`)
+- Prompt-scoped data is already available for core execution events:
+  - `execution_start`, `execution_success`, `execution_error`, `execution_interrupted`,
+    `executed`, `progress`, `progress_state`, and `executing` include `prompt_id` in
+    `../backend-3` and are forwarded unchanged through `../cloud-3`.
+  - Frontend currently *drops* `prompt_id` for `executing`; this can be fixed
+    without backend changes.
+- `progress_text` is a binary message containing only `nodeId` + text in
+  `../backend-3` (`send_progress_text`); `../cloud-3` forwards it as raw binary.
+  - Per-prompt progress text is **not possible** without backend changes.
+  - If we want it, we need to extend ComfyUI/backend to include `prompt_id` in
+    the binary payload or add a parallel JSON event.
+- `b_preview_with_metadata` includes `prompt_id` and is forwarded as binary; usable
+  as-is for prompt/workflow scoping.
+- Decide whether UI should filter by `client_id` (current tab only) or show all
+  user jobs; document and apply consistently.
+
+## Phase 1: Data model and execution state
+1. Refactor execution store to be prompt-centric:
+   - Replace `activePromptId` single value with:
+     - `promptStates: Record<promptId, PromptExecutionState>`.
+     - `runningPromptIds` derived from prompt states.
+     - `promptIdToWorkflowId` remains the primary routing map.
+   - Provide selectors:
+     - `getPromptProgress(promptId)`
+     - `getPromptNodeProgressStates(promptId)`
+     - `getWorkflowRunningPromptIds(workflowId)`
+     - `getActivePromptForWorkflow(workflowId)` (if needed)
+   - Redefine `isIdle` as `runningPromptIds.length === 0`.
+   - Keep backward-compat getters but scope to:
+     - active workflow tab, or
+     - "most recently started prompt".
+
+2. Update event handlers to write prompt-scoped state:
+   - `execution_start` creates prompt state.
+   - `progress_state` merges into `promptStates[promptId].nodeProgressStates`.
+   - `execution_success/error/interrupted` remove prompt state only for that id.
+   - Preserve initialization tracking per prompt.
+
+## Phase 2: Prompt-aware node progress and canvas updates
+1. Update graph/node progress to be scoped to the active workflow tab:
+   - Derive `nodeLocationProgressStates` from the prompt(s) mapped to the
+     active workflow only.
+   - Ensure `GraphCanvas.vue` applies progress for active workflow only.
+2. Update vue-node execution composables to use workflow-scoped progress.
+3. Update `groupNode` progress rendering to use prompt-scoped state.
+
+## Phase 3: Outputs and previews isolation
+1. Introduce per-workflow output maps in `imagePreviewStore`:
+   - `outputsByWorkflowId[workflowId][nodeLocatorId]`.
+   - `previewsByWorkflowId[workflowId][nodeLocatorId]`.
+2. When switching active workflow tab:
+   - Swap `app.nodeOutputs` and `app.nodePreviewImages` to the selected map.
+3. Update `executed` and `b_preview_with_metadata` handlers to:
+   - Use `prompt_id -> workflowId` mapping to store outputs/previews in the
+     correct workflow bucket.
+4. Update `ChangeTracker` and history loading paths to restore per-workflow
+   outputs without overwriting other workflows.
+
+## Phase 4: UI updates for multi-run visibility
+1. Queue overlay:
+   - `useQueueProgress` to compute per-job progress for all running tasks.
+   - `useJobList` to attach progress to each running item, not just one.
+   - `QueueOverlayActive` to show aggregated or multi-job state.
+2. Actionbar interrupt:
+   - Route interrupt to prompt(s) for the active workflow tab.
+   - Optionally add a "stop all running" action.
+3. Browser tab title + favicon:
+   - Use aggregate progress (e.g., max or average of running jobs) or show
+     count of running jobs with a generic progress indicator.
+
+## Phase 5: Browser-tab concurrency policy
+1. Decide and implement filtering:
+   - Option A: show only jobs for the current `client_id` in the UI.
+   - Option B: show all jobs for the user, but mark which client started them.
+2. Apply consistent filtering in:
+   - queue overlay,
+   - completion summary,
+   - progress favicon/title.
+
+## Phase 6: Tests and validation
+- Unit tests:
+  - `executionStore` selectors and lifecycle per prompt.
+  - `useQueueProgress` and `useJobList` showing per-job progress.
+- Update existing stories/tests that assume single `activePromptId`.
+- Manual validation checklist:
+  - Two workflows running in two in-app tabs: progress and outputs isolated.
+  - Two browser tabs running distinct workflows: no cross-talk in UI.
+  - Interrupt from actionbar affects intended prompt(s).
+
+## Phase 7: Rollout and cleanup
+- Remove deprecated single-prompt fields after migration is stable.
+- Update documentation/comments where prompt-scoped behavior is required.
+- Coordinate backend/WS schema changes with `../backend-3` and `../cloud-3`.