openapi: document QueueManageResponse body on POST /api/queue#14117
Conversation
mattmillerai
requested review from
Kosinkadink,
alexisrolland,
comfyanonymous,
guill,
kijai and
rattus128
as code owners
|
Warning Review limit reached
More reviews will be available in 15 minutes and 33 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR introduces a new QueueManageResponse schema in the OpenAPI specification and updates the POST /api/queue endpoint's 200 response to use it. The schema documents the shape of queue mutation responses with nullable deleted (array of prompt IDs) and cleared (boolean) fields. This change defines the contract for cloud runtime semantics around queue operations while accommodating cases where local behavior may return empty responses. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
![coderabbitai[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@openapi.yaml`:
- Around line 278-281: The OpenAPI operation paths./api/queue.post.responses.200
currently declares application/json with $ref to QueueManageResponse but the
local /queue handler may return an empty 200 body; update the spec to model the
empty-body case explicitly by either changing the success response to return 204
No Content for empty responses or making the 200 response schema optional/absent
(remove the application/json content) and add a separate 204 response entry, or
ensure the server always returns valid JSON matching QueueManageResponse; locate
the operation for /api/queue POST and modify responses.200 (and/or add
responses.204) and adjust or remove the application/json -> $ref:
"`#/components/schemas/QueueManageResponse`" accordingly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 15c68ece-9e3e-476b-8db5-4775c42d7abe
📒 Files selected for processing (1)
openapi.yaml
The Cloud runtime returns a JSON body from POST /api/queue describing which
prompts were deleted and whether the queue was cleared. The spec previously
declared a bare 200 with no schema, so generated clients had no type for the
response.
Adds a QueueManageResponse schema ({deleted, cleared}) and references it from
the 200 response. Tagged x-runtime: [cloud] with a [cloud-only] description:
local ComfyUI returns an empty 200 body, so both fields are nullable.
mattmillerai
force-pushed
the
matt/api-queue-manage-response
branch
from
ac7d299 to
e9e3055
Compare
…14118) * openapi: fix GET /api/hub/labels response to the label-catalog shape GET /api/hub/labels returns the catalog of available labels you can filter by, which the Cloud runtime serves as {labels: HubLabelInfo[]} (slug name, display_name, and a type category: tag/model/custom_node). The spec had this operation returning a bare array of HubLabel ({id, name, color}) — that schema models the label chips attached to a published workflow (HubWorkflow.labels), a different object. The catalog schema (HubLabelInfo) already existed but was unreferenced. Repoints the 200 response to a new HubLabelListResponse wrapper over the existing HubLabelInfo. HubLabel is unchanged and still used by HubWorkflow.labels. Endpoint remains x-runtime: [cloud]. * openapi: add Cloud-runtime fields (workflow_id, execution_error) to JobEntry (#14119) * openapi: add Cloud-runtime fields workflow_id, execution_error to JobEntry The Cloud runtime returns two additional fields on JobEntry that the spec didn't declare: - workflow_id: UUID of the Cloud workflow entity the job is associated with - execution_error: structured ComfyUI execution error for failed jobs (reuses the existing ExecutionError schema) Both tagged x-runtime: [cloud] with [cloud-only] descriptions; local ComfyUI does not populate them. * openapi: document Cloud-runtime request fields on POST /api/assets/export (#14120) The Cloud runtime accepts three request fields on /api/assets/export that the spec didn't declare: - job_ids: include all assets associated with the given jobs - naming_strategy: how to name files in the ZIP (enum, default group_by_job_time) - job_asset_name_filters: optional per-job asset-name allowlist Also drops asset_ids from required: the runtime supports exporting by job_ids alone, so neither field is individually required. /api/assets/export is already x-runtime: [cloud]; these are plain field additions under that endpoint-level tag.
2 participants
Summary
POST /api/queuedeclares a bare200with no response schema, so generated API clients have no type for what the endpoint returns.The Cloud runtime returns a JSON body describing the mutation result (which prompt IDs were deleted, and whether the queue was cleared). This documents that shape:
QueueManageResponseschema —{ deleted: string[], cleared: boolean }200responseRuntime tagging
Tagged
x-runtime: [cloud]with a[cloud-only]description. Local ComfyUI'spost_queuehandler returnsweb.Response(status=200)with no body, so both fields arenullable— local returns an empty body, Cloud populates it.No behavior change; spec-only.