Class TaskGraphService

Cancels a graph, everything in it that has not already settled, and everything it started.

Cancels children first: a parent marked Cancelled while children are still Pending would leave the dispatcher free to pick those children up, which is the opposite of what the caller asked for.

The verdict is the outcome, not the attempt (R2-9). This returned true unconditionally while logging each child that failed to cancel — so one failed save left that child Pending, told the caller cancellation had succeeded, and let the dispatcher run the child afterwards. The graph could then settle Complete and ANNOUNCE ITS COMPLETION into the conversation of a workflow the user had cancelled. A partial cancel now says so and names what survived; the graph stays active, so retrying is meaningful rather than cosmetic.

Marks a step Complete with an operator-supplied output.

Human steps are refused here on purpose: they already have a first-class completion path (TaskGraph.CompleteTask) with the assignee/elevation check, and this verb must not become the door that bypasses it.

Pauses a graph: nothing new is claimed until it is resumed. In-flight steps finish naturally and their completions land — a pause gates claiming and never touches a live claim, which is why there is no "what happens to the claim" question to answer.

Resumes a paused graph. Breakpoints and edge overrides survive — only the pause clears.

Returns a task to Pending so the dispatcher can run it again: a task that failed, or a Decision step holding an answer below its question's minConfidence.

A held Decision is retried from Complete. Its call succeeded, but an edge that reads the below-threshold answer holds rather than guess, and time is the only thing that can change it — so asking again is the way out, as it is for a failed call.

• Only the held questions are asked again, in one call. The answers it already gave that were usable are kept and merged with the new ones, because the graph has already acted on them: a fork's losing branch is already Skipped. Asking those questions again could flip the fork to a branch that is gone and leave neither branch to run, so a retry can settle a hold but never re-decide a fork. An edited inputPayload changes what the held questions are asked about; the kept answers stand.
• While it runs, every edge that reads it holds.
• If the new call fails, or cannot be made, the step stays Complete with the same usable answers, and each question it asked again holds with the reason. Retry it again.
• An edited inputPayload that is not a JSON object of named values is refused for a held Decision: the step would fail on it, and a failed step keeps no answers.
• Cost: the graph's cost rollup reaches a Decision's call through Configuration.runtime.promptRunID, which holds one ID and is replaced by each later call. So the rollup counts only the last call, as it does for a retried Prompt step. Every call is still recorded in its own MJ: AI Prompt Runs row and, for a graph an agent run submitted, as a Decision step on that run.

Also clears any Blocked dependents, since they were only blocked because this task failed — leaving them blocked would make the retry pointless, as the graph still could not progress past this node.

Replaces the graph's breakpoint set. Every ID must name a child of this graph — a breakpoint on a task in some other graph would gate nothing and silently lie to the person who set it.

Overrides one edge's condition verdict — the operator's answer for a path the engine cannot decide (a held graph) or decided wrongly (a broken guard). 'false' reads as "branch not taken" and cascades skips; 'true' opens the gate; null removes the override.

Declares a Pending step not-taken. Downstream dependents proceed — Skipped satisfies a prerequisite — and any open human request for the step is withdrawn so nobody keeps seeing an ask for work the operator decided against.

Arms a one-shot step allowance on a paused graph: 'one' releases the next eligible task, 'wave' releases the current frontier, a task ID releases exactly that task. The dispatcher consumes the allowance CAS-style, so two instances stepping the same graph release work once.

Validates and persists a task graph, returning as soon as it is durable.

Deliberately does NOT start execution: the dispatcher discovers Pending work by polling claimable tasks, so submission and execution are decoupled even within a single process. A submitted graph therefore survives the submitting request, the submitting agent run, and the submitting server — which is the entire point of Task rows over in-run state (D8).

Replaces a Pending step's input — the "edit the brief before stepping" move at a breakpoint. Applies to this run only; the step must not have started.

A guarded statement, not load-check-save. The in-memory Status === 'Pending' check plus task.Save() is an unconditional full-row UPDATE: a task claimed in the window between the load and the save has its claim columns reverted to the pre-claim snapshot while its body runs, and a second instance then claims it again — the step executes twice. See TaskClaimStore.TryUpdateInputPayload, which makes the check and the write one atomic operation whose rowcount is the answer.