* fix(web): cancel the underlying task when cancelling a task tool call (#1455) The ToolDetailPanel Cancel button fired onCancel, but App never supplied an onCancelToolCall handler, so clicking Cancel did nothing — a tool running as a task kept running on the server. App now captures the in-flight task-augmented call's taskId from the `toolCallTaskUpdated` event callToolStream dispatches, and the new onCancelToolCall handler cancels that task via the existing tasks API (reusing onCancelTask). The id is reset at the start of every call, so an ordinary (non-task) call's Cancel stays a no-op (no task to cancel, no request-abort channel yet) — preserving prior behavior. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat(web): show a toast when a task is cancelled Cancellation goes out as a `taskCancelled` event (not a status notification), so a running task's open 'Task <status>' toast would otherwise hang with no confirmation. Subscribe to `taskCancelled` and replace that toast (or show a fresh one) with a short auto-closing 'Task cancelled' toast, pruning the dead progress entry. Covers both cancel paths — the Tasks screen and the Tool detail panel. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(core): report a cancelled task as cancelled, not failed When a task is cancelled, the in-flight callToolStream rejects with a generic -32603 error, whose error path reported the task as "failed" — so the Tasks screen flashed FAILED until a manual refresh fetched the server's true "cancelled" state. InspectorClient now records cancelled task ids (set in cancelRequestorTask before the await, since cancelling unblocks the stream) and the stream's error path labels the terminal task "cancelled" with a matching status message. Cleared on disconnect. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * refactor: address review nits on task-cancel wiring - Prune the consumed taskId from cancelledTaskIds in the stream error path so the set can't grow across a long session (disconnect-clear remains the backstop for cancels whose task completed before the cancel landed). - Clear activeToolCallTaskIdRef before the cancel resolves so a rapid second Cancel click doesn't re-cancel the terminating task (which would surface a spurious 'Failed to cancel task' toast). Add a test. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
8d4363d0ea
commit
6bb49e55ba
1 changed files with 284 additions and 5 deletions
|
|
@ -191,6 +191,14 @@ export class InspectorClient extends InspectorClientEventTarget {
|
|||
};
|
||||
// Resource subscriptions
|
||||
private subscribedResources: Set<string> = new Set();
|
||||
// Task ids the user explicitly cancelled. A cancel makes the in-flight
|
||||
// `callToolStream` reject with a generic -32603 error, which the stream's
|
||||
// error path would otherwise report as a *failed* task — flashing "failed"
|
||||
// in the UI until a refresh fetches the server's true "cancelled" state.
|
||||
// Recording the id lets that path label the terminal task "cancelled"
|
||||
// instead, so it lands in the right state immediately (#1455). Cleared on
|
||||
// disconnect.
|
||||
private cancelledTaskIds: Set<string> = new Set();
|
||||
// Receiver tasks (server-initiated: server sends createMessage/elicit with params.task, server polls us)
|
||||
private receiverTasks: boolean;
|
||||
private receiverTaskTtlMs: number | (() => number);
|
||||
|
|
@ -1040,6 +1048,7 @@ export class InspectorClient extends InspectorClientEventTarget {
|
|||
this.pendingElicitations = [];
|
||||
// Clear resource subscriptions on disconnect
|
||||
this.subscribedResources.clear();
|
||||
this.cancelledTaskIds.clear();
|
||||
// Clear receiver tasks: stop TTL timers and drop records
|
||||
for (const record of this.receiverTaskRecords.values()) {
|
||||
if (record.cleanupTimeoutId != null) {
|
||||
|
|
@ -1182,6 +1191,10 @@ export class InspectorClient extends InspectorClientEventTarget {
|
|||
if (!this.client) {
|
||||
throw new Error("Client is not connected");
|
||||
}
|
||||
// Mark before awaiting: cancelling unblocks the in-flight callToolStream,
|
||||
// whose error message may arrive before this resolves — the stream's error
|
||||
// path reads this set to label the task "cancelled" rather than "failed".
|
||||
this.cancelledTaskIds.add(taskId);
|
||||
await this.client.experimental.tasks.cancelTask(
|
||||
taskId,
|
||||
this.getRequestOptions(),
|
||||
|
|
@ -1826,21 +1839,33 @@ export class InspectorClient extends InspectorClientEventTarget {
|
|||
message.error.message || "Task execution failed";
|
||||
error = new Error(errorMessage);
|
||||
if (taskId) {
|
||||
const failedTask: TaskWithOptionalCreatedAt = {
|
||||
// A user-cancelled task surfaces here as a generic error; report
|
||||
// it as "cancelled" (not "failed") so the UI lands on the true
|
||||
// terminal state immediately, matching what a refresh would show
|
||||
// (#1455).
|
||||
const cancelled = this.cancelledTaskIds.has(taskId);
|
||||
// Consume the marker — task ids are single-use, so this keeps the
|
||||
// set from growing across a long session of cancellations (the
|
||||
// disconnect-clear stays the backstop for cancels whose task
|
||||
// completed before the cancel landed and never hit this path).
|
||||
this.cancelledTaskIds.delete(taskId);
|
||||
const terminalTask: TaskWithOptionalCreatedAt = {
|
||||
taskId,
|
||||
ttl: null,
|
||||
status: "failed",
|
||||
statusMessage: errorMessage,
|
||||
status: cancelled ? "cancelled" : "failed",
|
||||
statusMessage: cancelled
|
||||
? "Client cancelled task execution."
|
||||
: errorMessage,
|
||||
lastUpdatedAt: new Date().toISOString(),
|
||||
};
|
||||
this.dispatchTypedEvent("toolCallTaskUpdated", {
|
||||
taskId,
|
||||
task: failedTask,
|
||||
task: terminalTask,
|
||||
error: message.error,
|
||||
});
|
||||
this.dispatchTypedEvent("requestorTaskUpdated", {
|
||||
taskId,
|
||||
task: failedTask,
|
||||
task: terminalTask,
|
||||
error: message.error,
|
||||
});
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in a new issue