Feature request
Return a structured outcome from Think.cancelSubmission() that identifies the state at cancellation, so a queued-message Delete can distinguish pending cancellation, aborting already-started work, an already-terminal no-op, and a missing submission.
Validation scope
Source/API review on 2026-09-15 against the latest released train (@cloudflare/think 0.18.0, @cloudflare/ai-chat 0.12.0, agents 0.23.0; release commit 5f7ad7e4edac2ec8dd1d6a31758f251cb52373fa) and upstream main a7b29135acf127cdf4a44114652970d0a22300de. The missing contract described below remains in both. This is source validation, not a new production or workerd reproduction. Our current application uses Think 0.17.0 / ai-chat 0.11.0 / agents 0.22.0.
Current behavior
cancelSubmission returns Promise<void>. Missing and terminal rows return immediately; pending/running rows are transitioned to aborted. Main adds queue/workflow handling but retains the same void return contract.
Our Delete UI needs three distinct answers: removed before execution, already started and aborted, or too late because work was already terminal. A read before cancellation races with promotion. We currently re-inspect after cancellation and use startedAt (status alone is insufficient because both paths can be aborted) to decide whether work ran and whether a separate terminal acknowledgement is owed.
Desired contract
Return an authoritative result from the cancellation operation, for example a discriminated outcome with prior status, whether execution had started, final/current status, and submission/request identity. Exact naming is open. Distinguish an accepted abort signal from confirmed execution settlement; do not promise rollback of an external side effect already underway.
Regression cases: cancel pending; cancel after pending-to-running promotion; cancel completed/error/skipped/already-aborted; cancel unknown ID; repeat the same cancellation; cancellation while termination is settling. The returned result should eliminate a separate race-sensitive inspection just to classify Delete.
#1731 addressed preventing a cancelled queued submission from later applying its messages. This is a separate API outcome-reporting request, not a reopening of that fixed execution bug.
Feature request
Return a structured outcome from
Think.cancelSubmission()that identifies the state at cancellation, so a queued-message Delete can distinguish pending cancellation, aborting already-started work, an already-terminal no-op, and a missing submission.Validation scope
Source/API review on 2026-09-15 against the latest released train (
@cloudflare/think0.18.0,@cloudflare/ai-chat0.12.0,agents0.23.0; release commit5f7ad7e4edac2ec8dd1d6a31758f251cb52373fa) and upstream maina7b29135acf127cdf4a44114652970d0a22300de. The missing contract described below remains in both. This is source validation, not a new production or workerd reproduction. Our current application uses Think 0.17.0 / ai-chat 0.11.0 / agents 0.22.0.Current behavior
cancelSubmissionreturnsPromise<void>. Missing and terminal rows return immediately; pending/running rows are transitioned toaborted. Main adds queue/workflow handling but retains the same void return contract.Our Delete UI needs three distinct answers: removed before execution, already started and aborted, or too late because work was already terminal. A read before cancellation races with promotion. We currently re-inspect after cancellation and use
startedAt(status alone is insufficient because both paths can beaborted) to decide whether work ran and whether a separate terminal acknowledgement is owed.Desired contract
Return an authoritative result from the cancellation operation, for example a discriminated outcome with prior status, whether execution had started, final/current status, and submission/request identity. Exact naming is open. Distinguish an accepted abort signal from confirmed execution settlement; do not promise rollback of an external side effect already underway.
Regression cases: cancel pending; cancel after pending-to-running promotion; cancel completed/error/skipped/already-aborted; cancel unknown ID; repeat the same cancellation; cancellation while termination is settling. The returned result should eliminate a separate race-sensitive inspection just to classify Delete.
#1731 addressed preventing a cancelled queued submission from later applying its messages. This is a separate API outcome-reporting request, not a reopening of that fixed execution bug.