Duplicated helpers also present in task-registry.ts

isActiveTaskStatus (lines 389–391) and isTerminalFlowStatus (lines 393–397) are defined verbatim in both task-executor.ts and task-registry.ts (lines ~83 and ~100 respectively). If the definition of "active" or "terminal" ever needs to change, both copies must be updated in sync.

These should either live in a shared utility (e.g., task-status-helpers.ts) and imported into both modules, or one module should import them from the other. As-is, a change to one copy won't automatically propagate.

This is a comment left during a code review.
Path: src/tasks/task-executor.ts
Line: 389-397

Comment:
**Duplicated helpers also present in `task-registry.ts`**

`isActiveTaskStatus` (lines 389–391) and `isTerminalFlowStatus` (lines 393–397) are defined verbatim in both `task-executor.ts` and `task-registry.ts` (lines ~83 and ~100 respectively). If the definition of "active" or "terminal" ever needs to change, both copies must be updated in sync.

These should either live in a shared utility (e.g., `task-status-helpers.ts`) and imported into both modules, or one module should import them from the other. As-is, a change to one copy won't automatically propagate.

How can I resolve this? If you propose a fix, please make it concise.

owner_key_mismatch and scope_kind_not_session errors are silently re-thrown

mapRunTaskInFlowCreateError handles cancel_requested, terminal, and parent_flow_not_found codes, but falls through to throw params.error for owner_key_mismatch and scope_kind_not_session.

In the current call site (runTaskInFlow) these codes are unreachable because ownerKey is always set from flow.ownerKey and scopeKind is hardcoded to "session". However, if a future call site ever creates a task with different params and routes through this helper, the raw ParentFlowLinkError would escape as an unhandled exception instead of returning a structured RunTaskInFlowResult.

Adding explicit branches (or at minimum a developer comment marking them as intentionally unreachable) would make the exhaustiveness contract clear to future maintainers:

// scope_kind_not_session and owner_key_mismatch are unreachable from runTaskInFlow
// because scopeKind is always "session" and ownerKey is always flow.ownerKey.
// Re-throw as a programmer error if somehow reached.
throw params.error;

This is a comment left during a code review.
Path: src/tasks/task-executor.ts
Line: 452-484

Comment:
**`owner_key_mismatch` and `scope_kind_not_session` errors are silently re-thrown**

`mapRunTaskInFlowCreateError` handles `cancel_requested`, `terminal`, and `parent_flow_not_found` codes, but falls through to `throw params.error` for `owner_key_mismatch` and `scope_kind_not_session`.

In the current call site (`runTaskInFlow`) these codes are unreachable because `ownerKey` is always set from `flow.ownerKey` and `scopeKind` is hardcoded to `"session"`. However, if a future call site ever creates a task with different params and routes through this helper, the raw `ParentFlowLinkError` would escape as an unhandled exception instead of returning a structured `RunTaskInFlowResult`.

Adding explicit branches (or at minimum a developer comment marking them as intentionally unreachable) would make the exhaustiveness contract clear to future maintainers:

```typescript
// scope_kind_not_session and owner_key_mismatch are unreachable from runTaskInFlow
// because scopeKind is always "session" and ownerKey is always flow.ownerKey.
// Re-throw as a programmer error if somehow reached.
throw params.error;
```

How can I resolve this? If you propose a fix, please make it concise.

Cancel active child tasks even when flow is terminal

This early terminal-status return skips the child-cancellation loop entirely, so cancelFlowById no longer cleans up queued/running child tasks when flow/task state is inconsistent (for example after partial restore or prior failed updates). Before this change, cancellation still attempted cancelTaskById first, which gave operators a recovery path; now the call exits with "Flow is already ..." and leaves active children running.

Useful? React with 👍 / 👎.

Retry cancel-intent write on flow revision conflicts

If requestFlowCancel returns a revision conflict, this branch returns immediately and never reaches the loop that cancels active child tasks. That means a concurrent metadata/state update on the flow can turn a cancel request into a no-op until someone retries manually, even though children are still running. The cancel path should reconcile with the latest revision (or retry) instead of aborting before task cancellation.

Useful? React with 👍 / 👎.

Treat accepted flow-cancel requests as successful

This branch reports cancelled: false even after cancelRequestedAt has already been persisted, so callers cannot distinguish “cancel request accepted, waiting for child shutdown” from a true failure. In this repo, flowsCancelCommand exits with an error whenever cancelled is false, which means operators see a failed cancel even though scheduling is already blocked and the flow is now in sticky-cancel mode.

Useful? React with 👍 / 👎.