- Place openapi.yaml in root directory where GitHub Actions workflow expects it
- Remove duplicate content and response keys that caused validation failures
- Use proper server URL format for validator compatibility
- Include essential endpoints and schema components for basic validation
This should resolve the 'Unable to render this definition' error in the OpenAPI validation workflow.
- Remove duplicate 'content' and '500' response entries that were causing validation failures
- Ensure proper YAML structure with unique response codes and single content definitions
- All OpenAPI spec validation tests now pass
Fixes GitHub Actions test failure in openapi-check workflow
Replace generic 'type: object' for /api/view_metadata endpoint with
comprehensive ModelMetadata schema that includes:
- Standard modelspec fields (date, architecture, title, description)
- Implementation details (format, license, author)
- Additional metadata with proper typing
- Base64 thumbnail support
This provides much better API documentation for model metadata
responses than the previous generic object definition.
Add 500 error responses to endpoints that previously only had 200:
- /api/prompt GET
- /api/queue GET
- /api/interrupt POST
- /api/free POST
- /api/features GET
- /api/history GET/POST
- /api/object_info endpoints
- /api/embeddings, /api/extensions, /api/system_stats
- /internal/logs and /internal/folder_paths endpoints
This provides complete error coverage for system failures and
improves API reliability documentation.
Replace generic additionalProperties: true for queue items with
detailed QueueItem schema that properly describes the array structure:
- Position number (integer)
- Prompt ID (UUID string)
- Workflow graph (object)
- Extra metadata (object)
- Output node IDs (array)
This provides much better API documentation and validation for
queue responses than the previous generic object definition.
- Add /api/features endpoint with ServerFeatures response schema
- Replace inline objects in /internal/logs/raw with RawLogsResponse schema
- Add LogEntry and TerminalSize component schemas for better reusability
- Replace inline LogsSubscribeRequest object with proper schema component
- Add required field constraints to LogsSubscribeRequest
This addresses the missing features endpoint and improves schema
consistency by moving complex inline objects to reusable components.
Enhance multipart/form-data schemas for image upload endpoints:
- Add required field constraints for image uploads
- Specify enum values for overwrite parameter ("true"/"false")
- Add default values for type ("input") and subfolder ("")
- Mark image and original_ref as required fields for mask uploads
- Improve field descriptions and validation
These changes make the API specification more precise and match
the actual server implementation requirements.
Replace inline object definitions for queue, history, and resource management
operations with reusable schema components:
- Add QueueManageRequest schema for /api/queue POST requests
- Add FreeResourcesRequest schema for /api/free POST requests
- Add HistoryManageRequest schema for /api/history POST requests
- Add UploadResponse schema for upload endpoints
This improves API consistency and reusability by moving common
object definitions to the components section.
This makes it easier to write asynchronous clients that submit requests, because they can store the task immediately.
Duplicate prompt IDs are rejected by the job queue.
Remove auth_token_comfy_org and api_key_comfy_org from extra_data before
storing prompt history to prevent sensitive authentication tokens from
being persisted in the history endpoint response.
Extends polling duration from 10 minutes to ~68 minutes (256 attempts × 16 seconds) to accommodate longer Kling API operations that were frequently timing out for users.
* Support for async execution functions
This commit adds support for node execution functions defined as async. When
a node's execution function is defined as async, we can continue
executing other nodes while it is processing.
Standard uses of `await` should "just work", but people will still have
to be careful if they spawn actual threads. Because torch doesn't really
have async/await versions of functions, this won't particularly help
with most locally-executing nodes, but it does work for e.g. web
requests to other machines.
In addition to the execute function, the `VALIDATE_INPUTS` and
`check_lazy_status` functions can also be defined as async, though we'll
only resolve one node at a time right now for those.
* Add the execution model tests to CI
* Add a missing file
It looks like this got caught by .gitignore? There's probably a better
place to put it, but I'm not sure what that is.
* Add the websocket library for automated tests
* Add additional tests for async error cases
Also fixes one bug that was found when an async function throws an error
after being scheduled on a task.
* Add a feature flags message to reduce bandwidth
We now only send 1 preview message of the latest type the client can
support.
We'll add a console warning when the client fails to send a feature
flags message at some point in the future.
* Add async tests to CI
* Don't actually add new tests in this PR
Will do it in a separate PR
* Resolve unit test in GPU-less runner
* Just remove the tests that GHA can't handle
* Change line endings to UNIX-style
* Avoid loading model_management.py so early
Because model_management.py has a top-level `logging.info`, we have to
be careful not to import that file before we call `setup_logging`. If we
do, we end up having the default logging handler registered in addition
to our custom one.