@knowledge-stack/ksapi 1.90.0 → 1.91.0

package/README.md

@@ -1,4 +1,4 @@
-# @knowledge-stack/ksapi@1.90.0
+# @knowledge-stack/ksapi@1.91.0
 
 A TypeScript SDK client for the localhost API.
 
@@ -213,6 +213,7 @@ All URIs are relative to *http://localhost:8000*
 *WorkflowRunsApi* | [**getWorkflowRun**](docs/WorkflowRunsApi.md#getworkflowrun) | **GET** /v1/workflow-runs/{run_id} | Get Workflow Run Handler
 *WorkflowRunsApi* | [**setWorkflowRunApproval**](docs/WorkflowRunsApi.md#setworkflowrunapprovaloperation) | **POST** /v1/workflow-runs/{run_id}/approval | Set Workflow Run Approval Handler
 *WorkflowRunsApi* | [**startWorkflowRun**](docs/WorkflowRunsApi.md#startworkflowrun) | **POST** /v1/workflow-runs/{run_id}/start | Start Workflow Run Handler
+*WorkflowRunsApi* | [**stopWorkflowRun**](docs/WorkflowRunsApi.md#stopworkflowrun) | **POST** /v1/workflow-runs/{run_id}/stop | Stop Workflow Run Handler
 *WorkflowRunsApi* | [**updateWorkflowRun**](docs/WorkflowRunsApi.md#updateworkflowrunoperation) | **PATCH** /v1/workflow-runs/{run_id} | Update Workflow Run Handler
 *WorkflowRunsApi* | [**workflowRunCallback**](docs/WorkflowRunsApi.md#workflowruncallbackoperation) | **POST** /v1/workflow-runs/{run_id}/callback | Workflow Run Callback Handler
 *WorkflowsApi* | [**cancelTemporalWorkflow**](docs/WorkflowsApi.md#canceltemporalworkflow) | **DELETE** /v1/workflows/{workflow_id} | Cancel Temporal Workflow Handler
@@ -465,7 +466,7 @@ and is automatically generated by the
 [OpenAPI Generator](https://openapi-generator.tech) project:
 
 - API version: `0.1.0`
-- Package version: `1.90.0`
+- Package version: `1.91.0`
 - Generator version: `7.21.0`
 - Build package: `org.openapitools.codegen.languages.TypeScriptFetchClientCodegen`
 

package/dist/apis/WorkflowDefinitionsApi.d.ts

@@ -89,21 +89,21 @@ export interface WorkflowDefinitionsApiInterface {
      * @param {string} definitionId
      * @param {string} [authorization]
      * @param {string} [ksUat]
-     * @param {Array<Blob>} [files] Files to ingest under the run\\\&#39;s &#x60;&#x60;inputs/&#x60;&#x60; folder. Each filename may include POSIX-style &#x60;&#x60;/&#x60;&#x60; separators to reconstruct a folder structure under &#x60;&#x60;inputs/&#x60;&#x60;.
-     * @param {string} [inputScope] JSON array of &#x60;&#x60;DOCUMENT&#x60;&#x60; or &#x60;&#x60;FOLDER&#x60;&#x60; path_part UUIDs referenced from the existing knowledge base. Combined with &#x60;&#x60;files&#x60;&#x60; in a single request to form the run\\\&#39;s input scope.
+     * @param {Array<Blob>} [files] DEPRECATED — do not send files here. Carrying file bytes on run creation makes the call block on synchronous S3 upload (the ~30s \\\&#39;Create run\\\&#39; wait). Instead create an empty draft (omit this field), then upload each file to the run\\\&#39;s &#x60;&#x60;inputs/&#x60;&#x60; folder via &#x60;&#x60;POST /v1/documents/ingest&#x60;&#x60; with &#x60;&#x60;path_part_id&#x60;&#x60; set to the run\\\&#39;s &#x60;&#x60;inputs_path_part_id&#x60;&#x60;; that path ingests asynchronously and auto-syncs the run\\\&#39;s state. This field will be removed once the FE has migrated.
+     * @param {string} [inputScope] JSON array of &#x60;&#x60;DOCUMENT&#x60;&#x60; or &#x60;&#x60;FOLDER&#x60;&#x60; path_part UUIDs referenced from the existing knowledge base, pinned onto the new draft\\\&#39;s input scope. Optional — omit for an empty draft and add references later via PATCH.
      * @param {string} [idempotencyKey] Optional key to prevent duplicate runs from retries.
      * @throws {RequiredError}
      * @memberof WorkflowDefinitionsApiInterface
      */
     createWorkflowRunRequestOpts(requestParameters: CreateWorkflowRunRequest): Promise<runtime.RequestOpts>;
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * @summary Create Workflow Run Handler
      * @param {string} definitionId
      * @param {string} [authorization]
      * @param {string} [ksUat]
-     * @param {Array<Blob>} [files] Files to ingest under the run\\\&#39;s &#x60;&#x60;inputs/&#x60;&#x60; folder. Each filename may include POSIX-style &#x60;&#x60;/&#x60;&#x60; separators to reconstruct a folder structure under &#x60;&#x60;inputs/&#x60;&#x60;.
-     * @param {string} [inputScope] JSON array of &#x60;&#x60;DOCUMENT&#x60;&#x60; or &#x60;&#x60;FOLDER&#x60;&#x60; path_part UUIDs referenced from the existing knowledge base. Combined with &#x60;&#x60;files&#x60;&#x60; in a single request to form the run\\\&#39;s input scope.
+     * @param {Array<Blob>} [files] DEPRECATED — do not send files here. Carrying file bytes on run creation makes the call block on synchronous S3 upload (the ~30s \\\&#39;Create run\\\&#39; wait). Instead create an empty draft (omit this field), then upload each file to the run\\\&#39;s &#x60;&#x60;inputs/&#x60;&#x60; folder via &#x60;&#x60;POST /v1/documents/ingest&#x60;&#x60; with &#x60;&#x60;path_part_id&#x60;&#x60; set to the run\\\&#39;s &#x60;&#x60;inputs_path_part_id&#x60;&#x60;; that path ingests asynchronously and auto-syncs the run\\\&#39;s state. This field will be removed once the FE has migrated.
+     * @param {string} [inputScope] JSON array of &#x60;&#x60;DOCUMENT&#x60;&#x60; or &#x60;&#x60;FOLDER&#x60;&#x60; path_part UUIDs referenced from the existing knowledge base, pinned onto the new draft\\\&#39;s input scope. Optional — omit for an empty draft and add references later via PATCH.
      * @param {string} [idempotencyKey] Optional key to prevent duplicate runs from retries.
      * @param {*} [options] Override http request option.
      * @throws {RequiredError}
@@ -111,7 +111,7 @@ export interface WorkflowDefinitionsApiInterface {
      */
     createWorkflowRunRaw(requestParameters: CreateWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowRunResponse>>;
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * Create Workflow Run Handler
      */
     createWorkflowRun(requestParameters: CreateWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
@@ -265,12 +265,12 @@ export declare class WorkflowDefinitionsApi extends runtime.BaseAPI implements W
      */
     createWorkflowRunRequestOpts(requestParameters: CreateWorkflowRunRequest): Promise<runtime.RequestOpts>;
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * Create Workflow Run Handler
      */
     createWorkflowRunRaw(requestParameters: CreateWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowRunResponse>>;
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * Create Workflow Run Handler
      */
     createWorkflowRun(requestParameters: CreateWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;

package/dist/apis/WorkflowDefinitionsApi.js

@@ -156,7 +156,7 @@ class WorkflowDefinitionsApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * Create Workflow Run Handler
      */
     createWorkflowRunRaw(requestParameters, initOverrides) {
@@ -167,7 +167,7 @@ class WorkflowDefinitionsApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * Create Workflow Run Handler
      */
     createWorkflowRun(requestParameters, initOverrides) {

package/dist/apis/WorkflowRunsApi.d.ts

@@ -38,6 +38,11 @@ export interface StartWorkflowRunRequest {
     authorization?: string | null;
     ksUat?: string | null;
 }
+export interface StopWorkflowRunRequest {
+    runId: string;
+    authorization?: string | null;
+    ksUat?: string | null;
+}
 export interface UpdateWorkflowRunOperationRequest {
     runId: string;
     updateWorkflowRunRequest: UpdateWorkflowRunRequest;
@@ -184,6 +189,31 @@ export interface WorkflowRunsApiInterface {
      * Start Workflow Run Handler
      */
     startWorkflowRun(requestParameters: StartWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
+    /**
+     * Creates request options for stopWorkflowRun without sending the request
+     * @param {string} runId
+     * @param {string} [authorization]
+     * @param {string} [ksUat]
+     * @throws {RequiredError}
+     * @memberof WorkflowRunsApiInterface
+     */
+    stopWorkflowRunRequestOpts(requestParameters: StopWorkflowRunRequest): Promise<runtime.RequestOpts>;
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * @summary Stop Workflow Run Handler
+     * @param {string} runId
+     * @param {string} [authorization]
+     * @param {string} [ksUat]
+     * @param {*} [options] Override http request option.
+     * @throws {RequiredError}
+     * @memberof WorkflowRunsApiInterface
+     */
+    stopWorkflowRunRaw(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowRunResponse>>;
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * Stop Workflow Run Handler
+     */
+    stopWorkflowRun(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
     /**
      * Creates request options for updateWorkflowRun without sending the request
      * @param {string} runId
@@ -309,6 +339,20 @@ export declare class WorkflowRunsApi extends runtime.BaseAPI implements Workflow
      * Start Workflow Run Handler
      */
     startWorkflowRun(requestParameters: StartWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
+    /**
+     * Creates request options for stopWorkflowRun without sending the request
+     */
+    stopWorkflowRunRequestOpts(requestParameters: StopWorkflowRunRequest): Promise<runtime.RequestOpts>;
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * Stop Workflow Run Handler
+     */
+    stopWorkflowRunRaw(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowRunResponse>>;
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * Stop Workflow Run Handler
+     */
+    stopWorkflowRun(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
     /**
      * Creates request options for updateWorkflowRun without sending the request
      */

package/dist/apis/WorkflowRunsApi.js

@@ -287,6 +287,50 @@ class WorkflowRunsApi extends runtime.BaseAPI {
             return yield response.value();
         });
     }
+    /**
+     * Creates request options for stopWorkflowRun without sending the request
+     */
+    stopWorkflowRunRequestOpts(requestParameters) {
+        return __awaiter(this, void 0, void 0, function* () {
+            if (requestParameters['runId'] == null) {
+                throw new runtime.RequiredError('runId', 'Required parameter "runId" was null or undefined when calling stopWorkflowRun().');
+            }
+            const queryParameters = {};
+            const headerParameters = {};
+            if (requestParameters['authorization'] != null) {
+                headerParameters['authorization'] = String(requestParameters['authorization']);
+            }
+            let urlPath = `/v1/workflow-runs/{run_id}/stop`;
+            urlPath = urlPath.replace(`{${"run_id"}}`, encodeURIComponent(String(requestParameters['runId'])));
+            return {
+                path: urlPath,
+                method: 'POST',
+                headers: headerParameters,
+                query: queryParameters,
+            };
+        });
+    }
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * Stop Workflow Run Handler
+     */
+    stopWorkflowRunRaw(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            const requestOptions = yield this.stopWorkflowRunRequestOpts(requestParameters);
+            const response = yield this.request(requestOptions, initOverrides);
+            return new runtime.JSONApiResponse(response, (jsonValue) => (0, index_1.WorkflowRunResponseFromJSON)(jsonValue));
+        });
+    }
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * Stop Workflow Run Handler
+     */
+    stopWorkflowRun(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            const response = yield this.stopWorkflowRunRaw(requestParameters, initOverrides);
+            return yield response.value();
+        });
+    }
     /**
      * Creates request options for updateWorkflowRun without sending the request
      */

package/dist/esm/apis/WorkflowDefinitionsApi.d.ts

@@ -89,21 +89,21 @@ export interface WorkflowDefinitionsApiInterface {
      * @param {string} definitionId
      * @param {string} [authorization]
      * @param {string} [ksUat]
-     * @param {Array<Blob>} [files] Files to ingest under the run\\\&#39;s &#x60;&#x60;inputs/&#x60;&#x60; folder. Each filename may include POSIX-style &#x60;&#x60;/&#x60;&#x60; separators to reconstruct a folder structure under &#x60;&#x60;inputs/&#x60;&#x60;.
-     * @param {string} [inputScope] JSON array of &#x60;&#x60;DOCUMENT&#x60;&#x60; or &#x60;&#x60;FOLDER&#x60;&#x60; path_part UUIDs referenced from the existing knowledge base. Combined with &#x60;&#x60;files&#x60;&#x60; in a single request to form the run\\\&#39;s input scope.
+     * @param {Array<Blob>} [files] DEPRECATED — do not send files here. Carrying file bytes on run creation makes the call block on synchronous S3 upload (the ~30s \\\&#39;Create run\\\&#39; wait). Instead create an empty draft (omit this field), then upload each file to the run\\\&#39;s &#x60;&#x60;inputs/&#x60;&#x60; folder via &#x60;&#x60;POST /v1/documents/ingest&#x60;&#x60; with &#x60;&#x60;path_part_id&#x60;&#x60; set to the run\\\&#39;s &#x60;&#x60;inputs_path_part_id&#x60;&#x60;; that path ingests asynchronously and auto-syncs the run\\\&#39;s state. This field will be removed once the FE has migrated.
+     * @param {string} [inputScope] JSON array of &#x60;&#x60;DOCUMENT&#x60;&#x60; or &#x60;&#x60;FOLDER&#x60;&#x60; path_part UUIDs referenced from the existing knowledge base, pinned onto the new draft\\\&#39;s input scope. Optional — omit for an empty draft and add references later via PATCH.
      * @param {string} [idempotencyKey] Optional key to prevent duplicate runs from retries.
      * @throws {RequiredError}
      * @memberof WorkflowDefinitionsApiInterface
      */
     createWorkflowRunRequestOpts(requestParameters: CreateWorkflowRunRequest): Promise<runtime.RequestOpts>;
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * @summary Create Workflow Run Handler
      * @param {string} definitionId
      * @param {string} [authorization]
      * @param {string} [ksUat]
-     * @param {Array<Blob>} [files] Files to ingest under the run\\\&#39;s &#x60;&#x60;inputs/&#x60;&#x60; folder. Each filename may include POSIX-style &#x60;&#x60;/&#x60;&#x60; separators to reconstruct a folder structure under &#x60;&#x60;inputs/&#x60;&#x60;.
-     * @param {string} [inputScope] JSON array of &#x60;&#x60;DOCUMENT&#x60;&#x60; or &#x60;&#x60;FOLDER&#x60;&#x60; path_part UUIDs referenced from the existing knowledge base. Combined with &#x60;&#x60;files&#x60;&#x60; in a single request to form the run\\\&#39;s input scope.
+     * @param {Array<Blob>} [files] DEPRECATED — do not send files here. Carrying file bytes on run creation makes the call block on synchronous S3 upload (the ~30s \\\&#39;Create run\\\&#39; wait). Instead create an empty draft (omit this field), then upload each file to the run\\\&#39;s &#x60;&#x60;inputs/&#x60;&#x60; folder via &#x60;&#x60;POST /v1/documents/ingest&#x60;&#x60; with &#x60;&#x60;path_part_id&#x60;&#x60; set to the run\\\&#39;s &#x60;&#x60;inputs_path_part_id&#x60;&#x60;; that path ingests asynchronously and auto-syncs the run\\\&#39;s state. This field will be removed once the FE has migrated.
+     * @param {string} [inputScope] JSON array of &#x60;&#x60;DOCUMENT&#x60;&#x60; or &#x60;&#x60;FOLDER&#x60;&#x60; path_part UUIDs referenced from the existing knowledge base, pinned onto the new draft\\\&#39;s input scope. Optional — omit for an empty draft and add references later via PATCH.
      * @param {string} [idempotencyKey] Optional key to prevent duplicate runs from retries.
      * @param {*} [options] Override http request option.
      * @throws {RequiredError}
@@ -111,7 +111,7 @@ export interface WorkflowDefinitionsApiInterface {
      */
     createWorkflowRunRaw(requestParameters: CreateWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowRunResponse>>;
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * Create Workflow Run Handler
      */
     createWorkflowRun(requestParameters: CreateWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
@@ -265,12 +265,12 @@ export declare class WorkflowDefinitionsApi extends runtime.BaseAPI implements W
      */
     createWorkflowRunRequestOpts(requestParameters: CreateWorkflowRunRequest): Promise<runtime.RequestOpts>;
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * Create Workflow Run Handler
      */
     createWorkflowRunRaw(requestParameters: CreateWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowRunResponse>>;
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * Create Workflow Run Handler
      */
     createWorkflowRun(requestParameters: CreateWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;

package/dist/esm/apis/WorkflowDefinitionsApi.js

@@ -120,7 +120,7 @@ export class WorkflowDefinitionsApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * Create Workflow Run Handler
      */
     createWorkflowRunRaw(requestParameters, initOverrides) {
@@ -131,7 +131,7 @@ export class WorkflowDefinitionsApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * Create Workflow Run Handler
      */
     createWorkflowRun(requestParameters, initOverrides) {

package/dist/esm/apis/WorkflowRunsApi.d.ts

@@ -38,6 +38,11 @@ export interface StartWorkflowRunRequest {
     authorization?: string | null;
     ksUat?: string | null;
 }
+export interface StopWorkflowRunRequest {
+    runId: string;
+    authorization?: string | null;
+    ksUat?: string | null;
+}
 export interface UpdateWorkflowRunOperationRequest {
     runId: string;
     updateWorkflowRunRequest: UpdateWorkflowRunRequest;
@@ -184,6 +189,31 @@ export interface WorkflowRunsApiInterface {
      * Start Workflow Run Handler
      */
     startWorkflowRun(requestParameters: StartWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
+    /**
+     * Creates request options for stopWorkflowRun without sending the request
+     * @param {string} runId
+     * @param {string} [authorization]
+     * @param {string} [ksUat]
+     * @throws {RequiredError}
+     * @memberof WorkflowRunsApiInterface
+     */
+    stopWorkflowRunRequestOpts(requestParameters: StopWorkflowRunRequest): Promise<runtime.RequestOpts>;
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * @summary Stop Workflow Run Handler
+     * @param {string} runId
+     * @param {string} [authorization]
+     * @param {string} [ksUat]
+     * @param {*} [options] Override http request option.
+     * @throws {RequiredError}
+     * @memberof WorkflowRunsApiInterface
+     */
+    stopWorkflowRunRaw(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowRunResponse>>;
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * Stop Workflow Run Handler
+     */
+    stopWorkflowRun(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
     /**
      * Creates request options for updateWorkflowRun without sending the request
      * @param {string} runId
@@ -309,6 +339,20 @@ export declare class WorkflowRunsApi extends runtime.BaseAPI implements Workflow
      * Start Workflow Run Handler
      */
     startWorkflowRun(requestParameters: StartWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
+    /**
+     * Creates request options for stopWorkflowRun without sending the request
+     */
+    stopWorkflowRunRequestOpts(requestParameters: StopWorkflowRunRequest): Promise<runtime.RequestOpts>;
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * Stop Workflow Run Handler
+     */
+    stopWorkflowRunRaw(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowRunResponse>>;
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * Stop Workflow Run Handler
+     */
+    stopWorkflowRun(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
     /**
      * Creates request options for updateWorkflowRun without sending the request
      */

package/dist/esm/apis/WorkflowRunsApi.js

@@ -251,6 +251,50 @@ export class WorkflowRunsApi extends runtime.BaseAPI {
             return yield response.value();
         });
     }
+    /**
+     * Creates request options for stopWorkflowRun without sending the request
+     */
+    stopWorkflowRunRequestOpts(requestParameters) {
+        return __awaiter(this, void 0, void 0, function* () {
+            if (requestParameters['runId'] == null) {
+                throw new runtime.RequiredError('runId', 'Required parameter "runId" was null or undefined when calling stopWorkflowRun().');
+            }
+            const queryParameters = {};
+            const headerParameters = {};
+            if (requestParameters['authorization'] != null) {
+                headerParameters['authorization'] = String(requestParameters['authorization']);
+            }
+            let urlPath = `/v1/workflow-runs/{run_id}/stop`;
+            urlPath = urlPath.replace(`{${"run_id"}}`, encodeURIComponent(String(requestParameters['runId'])));
+            return {
+                path: urlPath,
+                method: 'POST',
+                headers: headerParameters,
+                query: queryParameters,
+            };
+        });
+    }
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * Stop Workflow Run Handler
+     */
+    stopWorkflowRunRaw(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            const requestOptions = yield this.stopWorkflowRunRequestOpts(requestParameters);
+            const response = yield this.request(requestOptions, initOverrides);
+            return new runtime.JSONApiResponse(response, (jsonValue) => WorkflowRunResponseFromJSON(jsonValue));
+        });
+    }
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * Stop Workflow Run Handler
+     */
+    stopWorkflowRun(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            const response = yield this.stopWorkflowRunRaw(requestParameters, initOverrides);
+            return yield response.value();
+        });
+    }
     /**
      * Creates request options for updateWorkflowRun without sending the request
      */

package/docs/WorkflowDefinitionsApi.md

@@ -92,7 +92,7 @@ No authorization required
 
 Create Workflow Run Handler
 
-Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
 
 ### Example
 
@@ -114,9 +114,9 @@ async function example() {
     authorization: authorization_example,
     // string (optional)
     ksUat: ksUat_example,
-    // Array<Blob> | Files to ingest under the run\\\'s ``inputs/`` folder. Each filename may include POSIX-style ``/`` separators to reconstruct a folder structure under ``inputs/``. (optional)
+    // Array<Blob> | DEPRECATED — do not send files here. Carrying file bytes on run creation makes the call block on synchronous S3 upload (the ~30s \\\'Create run\\\' wait). Instead create an empty draft (omit this field), then upload each file to the run\\\'s ``inputs/`` folder via ``POST /v1/documents/ingest`` with ``path_part_id`` set to the run\\\'s ``inputs_path_part_id``; that path ingests asynchronously and auto-syncs the run\\\'s state. This field will be removed once the FE has migrated. (optional)
     files: /path/to/file.txt,
-    // string | JSON array of ``DOCUMENT`` or ``FOLDER`` path_part UUIDs referenced from the existing knowledge base. Combined with ``files`` in a single request to form the run\\\'s input scope. (optional)
+    // string | JSON array of ``DOCUMENT`` or ``FOLDER`` path_part UUIDs referenced from the existing knowledge base, pinned onto the new draft\\\'s input scope. Optional — omit for an empty draft and add references later via PATCH. (optional)
     inputScope: inputScope_example,
     // string | Optional key to prevent duplicate runs from retries. (optional)
     idempotencyKey: idempotencyKey_example,
@@ -142,8 +142,8 @@ example().catch(console.error);
 | **definitionId** | `string` |  | [Defaults to `undefined`] |
 | **authorization** | `string` |  | [Optional] [Defaults to `undefined`] |
 | **ksUat** | `string` |  | [Optional] [Defaults to `undefined`] |
-| **files** | `Array<Blob>` | Files to ingest under the run\\\&#39;s &#x60;&#x60;inputs/&#x60;&#x60; folder. Each filename may include POSIX-style &#x60;&#x60;/&#x60;&#x60; separators to reconstruct a folder structure under &#x60;&#x60;inputs/&#x60;&#x60;. | [Optional] |
-| **inputScope** | `string` | JSON array of &#x60;&#x60;DOCUMENT&#x60;&#x60; or &#x60;&#x60;FOLDER&#x60;&#x60; path_part UUIDs referenced from the existing knowledge base. Combined with &#x60;&#x60;files&#x60;&#x60; in a single request to form the run\\\&#39;s input scope. | [Optional] [Defaults to `undefined`] |
+| **files** | `Array<Blob>` | DEPRECATED — do not send files here. Carrying file bytes on run creation makes the call block on synchronous S3 upload (the ~30s \\\&#39;Create run\\\&#39; wait). Instead create an empty draft (omit this field), then upload each file to the run\\\&#39;s &#x60;&#x60;inputs/&#x60;&#x60; folder via &#x60;&#x60;POST /v1/documents/ingest&#x60;&#x60; with &#x60;&#x60;path_part_id&#x60;&#x60; set to the run\\\&#39;s &#x60;&#x60;inputs_path_part_id&#x60;&#x60;; that path ingests asynchronously and auto-syncs the run\\\&#39;s state. This field will be removed once the FE has migrated. | [Optional] |
+| **inputScope** | `string` | JSON array of &#x60;&#x60;DOCUMENT&#x60;&#x60; or &#x60;&#x60;FOLDER&#x60;&#x60; path_part UUIDs referenced from the existing knowledge base, pinned onto the new draft\\\&#39;s input scope. Optional — omit for an empty draft and add references later via PATCH. | [Optional] [Defaults to `undefined`] |
 | **idempotencyKey** | `string` | Optional key to prevent duplicate runs from retries. | [Optional] [Defaults to `undefined`] |
 
 ### Return type

package/docs/WorkflowRunsApi.md

@@ -9,6 +9,7 @@ All URIs are relative to *http://localhost:8000*
 | [**getWorkflowRun**](WorkflowRunsApi.md#getworkflowrun) | **GET** /v1/workflow-runs/{run_id} | Get Workflow Run Handler |
 | [**setWorkflowRunApproval**](WorkflowRunsApi.md#setworkflowrunapprovaloperation) | **POST** /v1/workflow-runs/{run_id}/approval | Set Workflow Run Approval Handler |
 | [**startWorkflowRun**](WorkflowRunsApi.md#startworkflowrun) | **POST** /v1/workflow-runs/{run_id}/start | Start Workflow Run Handler |
+| [**stopWorkflowRun**](WorkflowRunsApi.md#stopworkflowrun) | **POST** /v1/workflow-runs/{run_id}/stop | Stop Workflow Run Handler |
 | [**updateWorkflowRun**](WorkflowRunsApi.md#updateworkflowrunoperation) | **PATCH** /v1/workflow-runs/{run_id} | Update Workflow Run Handler |
 | [**workflowRunCallback**](WorkflowRunsApi.md#workflowruncallbackoperation) | **POST** /v1/workflow-runs/{run_id}/callback | Workflow Run Callback Handler |
 
@@ -386,6 +387,80 @@ No authorization required
 [[Back to top]](#) [[Back to API list]](../README.md#api-endpoints) [[Back to Model list]](../README.md#models) [[Back to README]](../README.md)
 
 
+## stopWorkflowRun
+
+> WorkflowRunResponse stopWorkflowRun(runId, authorization, ksUat)
+
+Stop Workflow Run Handler
+
+Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+
+### Example
+
+```ts
+import {
+  Configuration,
+  WorkflowRunsApi,
+} from '@knowledge-stack/ksapi';
+import type { StopWorkflowRunRequest } from '@knowledge-stack/ksapi';
+
+async function example() {
+  console.log("🚀 Testing @knowledge-stack/ksapi SDK...");
+  const api = new WorkflowRunsApi();
+
+  const body = {
+    // string
+    runId: 38400000-8cf0-11bd-b23e-10b96e4ef00d,
+    // string (optional)
+    authorization: authorization_example,
+    // string (optional)
+    ksUat: ksUat_example,
+  } satisfies StopWorkflowRunRequest;
+
+  try {
+    const data = await api.stopWorkflowRun(body);
+    console.log(data);
+  } catch (error) {
+    console.error(error);
+  }
+}
+
+// Run the test
+example().catch(console.error);
+```
+
+### Parameters
+
+
+| Name | Type | Description  | Notes |
+|------------- | ------------- | ------------- | -------------|
+| **runId** | `string` |  | [Defaults to `undefined`] |
+| **authorization** | `string` |  | [Optional] [Defaults to `undefined`] |
+| **ksUat** | `string` |  | [Optional] [Defaults to `undefined`] |
+
+### Return type
+
+[**WorkflowRunResponse**](WorkflowRunResponse.md)
+
+### Authorization
+
+No authorization required
+
+### HTTP request headers
+
+- **Content-Type**: Not defined
+- **Accept**: `application/json`
+
+
+### HTTP response details
+| Status code | Description | Response headers |
+|-------------|-------------|------------------|
+| **200** | Successful Response |  -  |
+| **422** | Validation Error |  -  |
+
+[[Back to top]](#) [[Back to API list]](../README.md#api-endpoints) [[Back to Model list]](../README.md#models) [[Back to README]](../README.md)
+
+
 ## updateWorkflowRun
 
 > WorkflowRunResponse updateWorkflowRun(runId, updateWorkflowRunRequest, authorization, ksUat)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@knowledge-stack/ksapi",
-  "version": "1.90.0",
+  "version": "1.91.0",
   "description": "OpenAPI client for @knowledge-stack/ksapi",
   "author": "OpenAPI-Generator",
   "repository": {

package/src/apis/WorkflowDefinitionsApi.ts

@@ -128,8 +128,8 @@ export interface WorkflowDefinitionsApiInterface {
      * @param {string} definitionId 
      * @param {string} [authorization] 
      * @param {string} [ksUat] 
-     * @param {Array<Blob>} [files] Files to ingest under the run\\\&#39;s &#x60;&#x60;inputs/&#x60;&#x60; folder. Each filename may include POSIX-style &#x60;&#x60;/&#x60;&#x60; separators to reconstruct a folder structure under &#x60;&#x60;inputs/&#x60;&#x60;.
-     * @param {string} [inputScope] JSON array of &#x60;&#x60;DOCUMENT&#x60;&#x60; or &#x60;&#x60;FOLDER&#x60;&#x60; path_part UUIDs referenced from the existing knowledge base. Combined with &#x60;&#x60;files&#x60;&#x60; in a single request to form the run\\\&#39;s input scope.
+     * @param {Array<Blob>} [files] DEPRECATED — do not send files here. Carrying file bytes on run creation makes the call block on synchronous S3 upload (the ~30s \\\&#39;Create run\\\&#39; wait). Instead create an empty draft (omit this field), then upload each file to the run\\\&#39;s &#x60;&#x60;inputs/&#x60;&#x60; folder via &#x60;&#x60;POST /v1/documents/ingest&#x60;&#x60; with &#x60;&#x60;path_part_id&#x60;&#x60; set to the run\\\&#39;s &#x60;&#x60;inputs_path_part_id&#x60;&#x60;; that path ingests asynchronously and auto-syncs the run\\\&#39;s state. This field will be removed once the FE has migrated.
+     * @param {string} [inputScope] JSON array of &#x60;&#x60;DOCUMENT&#x60;&#x60; or &#x60;&#x60;FOLDER&#x60;&#x60; path_part UUIDs referenced from the existing knowledge base, pinned onto the new draft\\\&#39;s input scope. Optional — omit for an empty draft and add references later via PATCH.
      * @param {string} [idempotencyKey] Optional key to prevent duplicate runs from retries.
      * @throws {RequiredError}
      * @memberof WorkflowDefinitionsApiInterface
@@ -137,13 +137,13 @@ export interface WorkflowDefinitionsApiInterface {
     createWorkflowRunRequestOpts(requestParameters: CreateWorkflowRunRequest): Promise<runtime.RequestOpts>;
 
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * @summary Create Workflow Run Handler
      * @param {string} definitionId 
      * @param {string} [authorization] 
      * @param {string} [ksUat] 
-     * @param {Array<Blob>} [files] Files to ingest under the run\\\&#39;s &#x60;&#x60;inputs/&#x60;&#x60; folder. Each filename may include POSIX-style &#x60;&#x60;/&#x60;&#x60; separators to reconstruct a folder structure under &#x60;&#x60;inputs/&#x60;&#x60;.
-     * @param {string} [inputScope] JSON array of &#x60;&#x60;DOCUMENT&#x60;&#x60; or &#x60;&#x60;FOLDER&#x60;&#x60; path_part UUIDs referenced from the existing knowledge base. Combined with &#x60;&#x60;files&#x60;&#x60; in a single request to form the run\\\&#39;s input scope.
+     * @param {Array<Blob>} [files] DEPRECATED — do not send files here. Carrying file bytes on run creation makes the call block on synchronous S3 upload (the ~30s \\\&#39;Create run\\\&#39; wait). Instead create an empty draft (omit this field), then upload each file to the run\\\&#39;s &#x60;&#x60;inputs/&#x60;&#x60; folder via &#x60;&#x60;POST /v1/documents/ingest&#x60;&#x60; with &#x60;&#x60;path_part_id&#x60;&#x60; set to the run\\\&#39;s &#x60;&#x60;inputs_path_part_id&#x60;&#x60;; that path ingests asynchronously and auto-syncs the run\\\&#39;s state. This field will be removed once the FE has migrated.
+     * @param {string} [inputScope] JSON array of &#x60;&#x60;DOCUMENT&#x60;&#x60; or &#x60;&#x60;FOLDER&#x60;&#x60; path_part UUIDs referenced from the existing knowledge base, pinned onto the new draft\\\&#39;s input scope. Optional — omit for an empty draft and add references later via PATCH.
      * @param {string} [idempotencyKey] Optional key to prevent duplicate runs from retries.
      * @param {*} [options] Override http request option.
      * @throws {RequiredError}
@@ -152,7 +152,7 @@ export interface WorkflowDefinitionsApiInterface {
     createWorkflowRunRaw(requestParameters: CreateWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowRunResponse>>;
 
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * Create Workflow Run Handler
      */
     createWorkflowRun(requestParameters: CreateWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
@@ -421,7 +421,7 @@ export class WorkflowDefinitionsApi extends runtime.BaseAPI implements WorkflowD
     }
 
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * Create Workflow Run Handler
      */
     async createWorkflowRunRaw(requestParameters: CreateWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowRunResponse>> {
@@ -432,7 +432,7 @@ export class WorkflowDefinitionsApi extends runtime.BaseAPI implements WorkflowD
     }
 
     /**
-     * Trigger a workflow run from uploaded files and/or KB references.  The merged endpoint accepts both kinds of input in one multipart request. Each uploaded file is ingested under ``runs/<id>/inputs/`` (S3 + DB rows only; no Temporal pipeline). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner. A request that supplies neither is rejected.
+     * Create a NOT_STARTED run draft, optionally seeded with KB references.  All three fields are optional: an empty request creates an empty draft instantly (the two-step flow — the FE then uploads files into the run\'s ``inputs/`` folder and/or PATCHes ``input_scope`` before Start). Each ``input_scope`` entry is resolved per its part_type: a DOCUMENT is pinned to its active ``DOCUMENT_VERSION``; a FOLDER is pinned by reference only and read live by the runner.  ``files`` is DEPRECATED — see the field description. When supplied, uploads are still ingested under ``runs/<id>/inputs/`` so callers mid-migration keep working, but the call blocks on synchronous S3 upload.
      * Create Workflow Run Handler
      */
     async createWorkflowRun(requestParameters: CreateWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse> {

package/src/apis/WorkflowRunsApi.ts

@@ -72,6 +72,12 @@ export interface StartWorkflowRunRequest {
     ksUat?: string | null;
 }
 
+export interface StopWorkflowRunRequest {
+    runId: string;
+    authorization?: string | null;
+    ksUat?: string | null;
+}
+
 export interface UpdateWorkflowRunOperationRequest {
     runId: string;
     updateWorkflowRunRequest: UpdateWorkflowRunRequest;
@@ -235,6 +241,34 @@ export interface WorkflowRunsApiInterface {
      */
     startWorkflowRun(requestParameters: StartWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
 
+    /**
+     * Creates request options for stopWorkflowRun without sending the request
+     * @param {string} runId 
+     * @param {string} [authorization] 
+     * @param {string} [ksUat] 
+     * @throws {RequiredError}
+     * @memberof WorkflowRunsApiInterface
+     */
+    stopWorkflowRunRequestOpts(requestParameters: StopWorkflowRunRequest): Promise<runtime.RequestOpts>;
+
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * @summary Stop Workflow Run Handler
+     * @param {string} runId 
+     * @param {string} [authorization] 
+     * @param {string} [ksUat] 
+     * @param {*} [options] Override http request option.
+     * @throws {RequiredError}
+     * @memberof WorkflowRunsApiInterface
+     */
+    stopWorkflowRunRaw(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowRunResponse>>;
+
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * Stop Workflow Run Handler
+     */
+    stopWorkflowRun(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
+
     /**
      * Creates request options for updateWorkflowRun without sending the request
      * @param {string} runId 
@@ -572,6 +606,57 @@ export class WorkflowRunsApi extends runtime.BaseAPI implements WorkflowRunsApiI
         return await response.value();
     }
 
+    /**
+     * Creates request options for stopWorkflowRun without sending the request
+     */
+    async stopWorkflowRunRequestOpts(requestParameters: StopWorkflowRunRequest): Promise<runtime.RequestOpts> {
+        if (requestParameters['runId'] == null) {
+            throw new runtime.RequiredError(
+                'runId',
+                'Required parameter "runId" was null or undefined when calling stopWorkflowRun().'
+            );
+        }
+
+        const queryParameters: any = {};
+
+        const headerParameters: runtime.HTTPHeaders = {};
+
+        if (requestParameters['authorization'] != null) {
+            headerParameters['authorization'] = String(requestParameters['authorization']);
+        }
+
+
+        let urlPath = `/v1/workflow-runs/{run_id}/stop`;
+        urlPath = urlPath.replace(`{${"run_id"}}`, encodeURIComponent(String(requestParameters['runId'])));
+
+        return {
+            path: urlPath,
+            method: 'POST',
+            headers: headerParameters,
+            query: queryParameters,
+        };
+    }
+
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * Stop Workflow Run Handler
+     */
+    async stopWorkflowRunRaw(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowRunResponse>> {
+        const requestOptions = await this.stopWorkflowRunRequestOpts(requestParameters);
+        const response = await this.request(requestOptions, initOverrides);
+
+        return new runtime.JSONApiResponse(response, (jsonValue) => WorkflowRunResponseFromJSON(jsonValue));
+    }
+
+    /**
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  While a run sits ``IN_PROGRESS`` its run thread is read-only: every new USER message 409s (``run_in_progress``). A user \"stop\" must therefore move the run out of ``IN_PROGRESS``. We mark it ``FAILED`` (\"Stopped by user\") with a pure DB write that does **not** depend on Temporal — so this same call also recovers a run already stranded ``IN_PROGRESS`` by a cancel whose terminal callback never landed (the permanent-brick case) — then best-effort cancel its Temporal workflow.  Idempotent: a run already in a terminal state (or not yet started) is returned unchanged. The terminal-state guard in ``mark_run_failed`` plus the callback handler\'s ``already_terminal`` no-op make a real completion landing concurrently safe (last writer is ignored, never an error).
+     * Stop Workflow Run Handler
+     */
+    async stopWorkflowRun(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse> {
+        const response = await this.stopWorkflowRunRaw(requestParameters, initOverrides);
+        return await response.value();
+    }
+
     /**
      * Creates request options for updateWorkflowRun without sending the request
      */