MCP: the Render queue and wait_for_jobs (#193) #207

Merged

crowmaki merged 2 commits from issue-193-mcp-queue into main

2026-10-13 06:23:05 +00:00

crowmaki commented

2026-10-13 06:22:19 +00:00

Owner

Closes #193. Part of #157.

What changed

read_queue returns the Render queue's controls (paused, holdFinals, reopened, comfyOffline) and its jobs, as the Queue panel shows them.
Queue controls: set_queue_paused, set_hold_finals, hold_job, move_job, run_jobs_next, cancel_job and dismiss_job. Each one calls the existing ApiImpl command and returns read_queue.
wait_for_jobs(jobIds, timeoutSeconds) blocks until every job is done or cancelled. It returns early on a failed job, when ComfyUI is offline, when the queue is paused with a job still waiting, and when a waiting job is on hold. Otherwise it returns timedOut. The timeout is capped at 600 s. The reply gives each job's state: queued, running, done, failed (with the error) or cancelled.
- It wakes on the Project's change events, with a 1 s recheck as a fallback. It does not busy-poll.
- It ends with an error if another Project opens while it waits. Otherwise every job would look cancelled.
Progress: when the request carries a progress token, the running job's progress goes out as MCP progress notifications. Progress counts finished jobs out of the total and never goes down. The notifications come from the same feed the Queue panel follows: ProgressListeners now holds both window channels and MCP waits.
Core: ProjectSession::job_statuses reads a job's state whether or not the queue still shows it, so a wait can tell done, failed and cancelled jobs apart.

Beyond the issue

held is an extra early-return outcome. A job on hold never starts, so waiting for the full timeout would do nothing.

Tests

src-tauri/tests/mcp_queue.rs has 13 tests at the MCP boundary:

each control changes the queue read
the wait finishes, fails early, and returns early on pause, hold and ComfyUI offline
the wait times out
a job cancelled during the wait reports cancelled
an unknown id and an empty list are refused
a Project switch during the wait gives an error
progress notifications arrive during the wait

The full workspace suite passes. Clippy shows the same warnings as main.

Closes #193. Part of #157. ## What changed - **`read_queue`** returns the Render queue's controls (paused, holdFinals, reopened, comfyOffline) and its jobs, as the Queue panel shows them. - **Queue controls:** `set_queue_paused`, `set_hold_finals`, `hold_job`, `move_job`, `run_jobs_next`, `cancel_job` and `dismiss_job`. Each one calls the existing `ApiImpl` command and returns `read_queue`. - **`wait_for_jobs(jobIds, timeoutSeconds)`** blocks until every job is done or cancelled. It returns early on a failed job, when ComfyUI is offline, when the queue is paused with a job still waiting, and when a waiting job is on hold. Otherwise it returns `timedOut`. The timeout is capped at 600 s. The reply gives each job's state: `queued`, `running`, `done`, `failed` (with the error) or `cancelled`. - It wakes on the Project's change events, with a 1 s recheck as a fallback. It does not busy-poll. - It ends with an error if another Project opens while it waits. Otherwise every job would look cancelled. - **Progress:** when the request carries a progress token, the running job's progress goes out as MCP progress notifications. Progress counts finished jobs out of the total and never goes down. The notifications come from the same feed the Queue panel follows: `ProgressListeners` now holds both window channels and MCP waits. - **Core:** `ProjectSession::job_statuses` reads a job's state whether or not the queue still shows it, so a wait can tell done, failed and cancelled jobs apart. ## Beyond the issue `held` is an extra early-return outcome. A job on hold never starts, so waiting for the full timeout would do nothing. ## Tests `src-tauri/tests/mcp_queue.rs` has 13 tests at the MCP boundary: - each control changes the queue read - the wait finishes, fails early, and returns early on pause, hold and ComfyUI offline - the wait times out - a job cancelled during the wait reports `cancelled` - an unknown id and an empty list are refused - a Project switch during the wait gives an error - progress notifications arrive during the wait The full workspace suite passes. Clippy shows the same warnings as `main`.

crowmaki added 2 commits

2026-10-13 06:22:19 +00:00

MCP: the Render queue and wait_for_jobs (#193 ) 8ad4ccf065

A harness reads the Render queue with its controls, and pauses, holds,
moves, runs next, cancels and dismisses jobs; each control returns the
queue read. wait_for_jobs blocks until the jobs finish, returning early
when one fails, ComfyUI goes offline, the queue is paused with a job
waiting, or a job waits on a hold, and otherwise times out (capped at
600 seconds). It wakes on the Project's changes and sends the running
job's progress, from the feed the Queue panel follows, as MCP progress
notifications.

The core reads a job's status whether or not the queue still shows it,
so a wait tells done, failed and cancelled jobs apart.

Address review of #193 9c460fee6d

- wait_for_jobs ends with an error when another Project opens mid-wait,
  instead of reporting every job cancelled.
- An unknown job id's error says it may have been cancelled with its Take.
- The wait outcome is a typed enum; the change counter is change_count.
- Tests for both, and for an empty jobIds.

crowmaki merged commit fcdaae6f04 into main

2026-10-13 06:23:05 +00:00

crowmaki deleted branch issue-193-mcp-queue

2026-10-13 06:23:05 +00:00

crowmaki referenced this pull request from a commit

2026-10-13 06:23:06 +00:00

Merge pull request 'MCP: the Render queue and wait_for_jobs (#193)' (#207) from issue-193-mcp-queue into main