[Bug]: task_cancel omits queued-task cancellation semantics #26119

Summary

The task_cancel section in docs/orchestration-v2/orchestrator-mcp-server.md says a nonterminal task without an interruptible run is rejected and describes Stop holding queued turns without explaining the additional removal of the cancelled task’s own queued turn. Current code explicitly accepts a matching queued run, including a held one, and cancels that queued run after Stop. This leaves readers with an incorrect contract for queued-only tasks.

Steps to reproduce

1. In a checkout of each baseline under Version or commit, read the task_cancel section of the document.
2. In apps/server/src/mcp/OrchestratorMcpService.ts, inspect cancelTask: the rejection guard permits a queued run matching the task ID or original child run ID, even without a latest active run.
3. Inspect stopChild in the same method. After thread.stop, it dispatches queued-run.cancel for that task’s matching queued runs, without excluding previously held runs.
4. Compare with dispatchThreadStop in apps/server/src/orchestration-v2/Orchestrator.ts, which holds the queue. This distinguishes general Stop behavior from the additional task-specific cancellation.

These source/document comparisons were executed for all three baselines. No live queued task was created or cancelled.

Expected behavior

The existing repository documentation policy requires stale documented constraints to be rewritten or removed. The task_cancel description should distinguish queued-only cancellation from rejection, and general Stop queue preservation from removal of the cancelled task’s own queued turn.

Actual behavior

The inspected source has both a queued-run exception in the rejection guard and a task-specific queued-run cancellation loop. The document still says “A nonterminal task with no interruptible run is rejected” and gives only the general queue-holding description.

The distinction matters: thread.stop holds queued work, but the subsequent loop cancels queued runs where delegatedTaskId matches the cancelled task or run.id matches its original child run. Other queued runs remain held by Stop; the loop does not indiscriminately cancel every queued turn. A matching held run still has status === "queued" and is included. No runtime result was measured.

Evidence

• Expected source: cancellation prose and the repository documentation policy cited above.
• Failure source: queued-run rejection exception, Stop and task-specific cancellation, and general Stop implementation; the same relevant clauses and source branches were read at both release tags.
• Evidence provenance: observed
• Local verification: reproduced
• Reproduction completeness: complete

The reproduced failure is the documentation/source mismatch. The source branches explain the mismatch; runtime operations and project tests were not executed.

The orchestration-v2 document-set README describes target architecture. This report is limited to this page’s concrete present-tense description of implemented MCP behavior, and does not ask to implement the obsolete description. The repository documentation policy permits rewriting or removing stale guidance and linking to authoritative source.

Restoration check

Repeat the source/document comparison. Passing guidance accurately describes cancellation of queued-only tasks, removal of the cancelled task’s own queued turn (including held ones), and preservation as held of other queued work under Stop. It should still distinguish a task with neither active/nested work nor a matching queued run, where rejection can apply. No change to queue or cancellation behavior is requested.

Version or commit

Inspected repository source at current main 4914cdd98f3d15ab2ddef34f0af70d3d68a2d8e5, latest published nightly v0.1.4-nightly.20261027.3783 (dc84b0962efa4f4e05ef392c08986a9cd7c994d1), and latest stable v0.1.3 (d2c440312e5f39d59827ed466838a623516454d6). This is a platform-independent documentation/source comparison. No T3 server, provider session, live MCP mutation, or test suite was run.

Area

Docs

Impact

Minor bug or occasional failure.

Workaround

Read the queued-run guard and task-specific cancellation loop before relying on the prose. This source-level workaround was verified; no alternative live workflow was tested.

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

References

Open report #15670 and open PR #23199 cover the tool count and recurring-task discoverability. They do not correct this contract. No comment is requested on either thread.

Closed PR #15201 was superseded by merged PR #21487. Its closure explicitly identifies removal of a task’s own held queued run. The current documentation still omits that distinction; this report concerns documentation, not reopening the runtime fix.

Triage assessment

• Impact level: P2
• Assessment status: provisional
• Impact basis: The stale description can mislead a coordinator deciding whether a queued task can be cancelled and whether its prompt remains resumable. No live misuse, data loss, or frequency was observed.
• Workaround status: available
• Workaround basis: Read the queued-run guard and task-specific cancellation loop before relying on the prose. This source-level workaround was verified; no alternative live workflow was tested.