From 2eb586b422a78927ecd7ba0d45627c3e34e23eb3 Mon Sep 17 00:00:00 2001 From: "roomote[bot]" <219738659+roomote[bot]@users.noreply.github.com> Date: Mon, 21 Jul 2025 11:16:38 -0700 Subject: [PATCH] fix: properly distinguish between user cancellations and API failures (#6025) Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com> Co-authored-by: Roo Code Co-authored-by: Daniel <57051444+daniel-lxs@users.noreply.github.com> --- src/core/task/Task.ts | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/core/task/Task.ts b/src/core/task/Task.ts index 53b8ef5b87..ccd24b7d71 100644 --- a/src/core/task/Task.ts +++ b/src/core/task/Task.ts @@ -1442,16 +1442,18 @@ export class Task extends EventEmitter { // could be in (i.e. could have streamed some tools the user // may have executed), so we just resort to replicating a // cancel task. - this.abortTask() - // Check if this was a user-initiated cancellation - // If this.abort is true, it means the user clicked cancel, so we should + // Check if this was a user-initiated cancellation BEFORE calling abortTask + // If this.abort is already true, it means the user clicked cancel, so we should // treat this as "user_cancelled" rather than "streaming_failed" const cancelReason = this.abort ? "user_cancelled" : "streaming_failed" const streamingFailedMessage = this.abort ? undefined : (error.message ?? JSON.stringify(serializeError(error), null, 2)) + // Now call abortTask after determining the cancel reason + await this.abortTask() + await abortStream(cancelReason, streamingFailedMessage) const history = await provider?.getTaskWithId(this.taskId)