@knowledge-stack/ksapi 1.130.0 → 1.131.1

package/README.md

@@ -1,4 +1,4 @@
-# @knowledge-stack/ksapi@1.130.0
+# @knowledge-stack/ksapi@1.131.1
 
 A TypeScript SDK client for the localhost API.
 
@@ -617,7 +617,7 @@ and is automatically generated by the
 [OpenAPI Generator](https://openapi-generator.tech) project:
 
 - API version: `0.1.0`
-- Package version: `1.130.0`
+- Package version: `1.131.1`
 - Generator version: `7.21.0`
 - Build package: `org.openapitools.codegen.languages.TypeScriptFetchClientCodegen`
 

package/dist/apis/WorkflowRunsApi.d.ts

@@ -287,7 +287,7 @@ export interface 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).
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * @summary Stop Workflow Run Handler
      * @param {string} runId
      * @param {*} [options] Override http request option.
@@ -296,7 +296,7 @@ export interface 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 a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * Stop Workflow Run Handler
      */
     stopWorkflowRun(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
@@ -464,12 +464,12 @@ export declare class WorkflowRunsApi extends runtime.BaseAPI implements Workflow
      */
     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 a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * 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 a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * Stop Workflow Run Handler
      */
     stopWorkflowRun(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;

package/dist/apis/WorkflowRunsApi.js

@@ -530,7 +530,7 @@ class WorkflowRunsApi extends runtime.BaseAPI {
         });
     }
     /**
-     * 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 a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * Stop Workflow Run Handler
      */
     stopWorkflowRunRaw(requestParameters, initOverrides) {
@@ -541,7 +541,7 @@ class WorkflowRunsApi extends runtime.BaseAPI {
         });
     }
     /**
-     * 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 a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * Stop Workflow Run Handler
      */
     stopWorkflowRun(requestParameters, initOverrides) {

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

@@ -287,7 +287,7 @@ export interface 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).
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * @summary Stop Workflow Run Handler
      * @param {string} runId
      * @param {*} [options] Override http request option.
@@ -296,7 +296,7 @@ export interface 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 a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * Stop Workflow Run Handler
      */
     stopWorkflowRun(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
@@ -464,12 +464,12 @@ export declare class WorkflowRunsApi extends runtime.BaseAPI implements Workflow
      */
     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 a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * 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 a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * Stop Workflow Run Handler
      */
     stopWorkflowRun(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;

package/dist/esm/apis/WorkflowRunsApi.js

@@ -494,7 +494,7 @@ export class WorkflowRunsApi extends runtime.BaseAPI {
         });
     }
     /**
-     * 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 a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * Stop Workflow Run Handler
      */
     stopWorkflowRunRaw(requestParameters, initOverrides) {
@@ -505,7 +505,7 @@ export class WorkflowRunsApi extends runtime.BaseAPI {
         });
     }
     /**
-     * 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 a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * Stop Workflow Run Handler
      */
     stopWorkflowRun(requestParameters, initOverrides) {

package/docs/WorkflowRunsApi.md

@@ -680,7 +680,7 @@ example().catch(console.error);
 
 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).
+Stop a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
 
 ### Example
 

package/package.json

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

package/src/apis/WorkflowRunsApi.ts

@@ -376,7 +376,7 @@ export interface 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).
+     * Stop a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * @summary Stop Workflow Run Handler
      * @param {string} runId 
      * @param {*} [options] Override http request option.
@@ -386,7 +386,7 @@ export interface 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 a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * Stop Workflow Run Handler
      */
     stopWorkflowRun(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse>;
@@ -1004,7 +1004,7 @@ export class WorkflowRunsApi extends runtime.BaseAPI implements WorkflowRunsApiI
     }
 
     /**
-     * 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 a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * Stop Workflow Run Handler
      */
     async stopWorkflowRunRaw(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<WorkflowRunResponse>> {
@@ -1015,7 +1015,7 @@ export class WorkflowRunsApi extends runtime.BaseAPI implements WorkflowRunsApiI
     }
 
     /**
-     * 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 a running workflow run, terminalizing it so its thread un-bricks.  Marks the run ``FAILED`` (\"Stopped by user\") with a pure DB write (no Temporal dependency, so it also recovers a run stranded ``IN_PROGRESS`` by a lost cancel callback), then best-effort revokes the streaming reply\'s lease and cancels the Temporal workflow. Revoking the lease is what makes stop authoritative — the cancel only *requests* a cooperative stop; see docs/api/notification_system.md for the lease protocol.  Idempotent: a terminal or not-yet-started run is returned unchanged (the ``mark_run_failed`` guard + the callback\'s ``already_terminal`` no-op keep a real completion landing concurrently safe).
      * Stop Workflow Run Handler
      */
     async stopWorkflowRun(requestParameters: StopWorkflowRunRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<WorkflowRunResponse> {