fix: ensure cancel button properly stops streaming responses

[roomote]

Description

This PR fixes issue #7014 where the Cancel button does not stop the response streaming process when a model gets stuck in a streaming loop.

Problem

The issue was caused by a race condition where:

1. When the user clicks Cancel, the UI sends a cancelTask message
2. The cancelTask handler calls abortTask() which sets this.abort = true
3. However, if a stream error occurs before abortTask() is called, the error handler checks this.abort to determine if it was user-cancelled or a streaming failure
4. This race condition could cause the cancel to be incorrectly treated as a streaming failure

Solution

The fix ensures proper cancellation by:

1. Setting the abort flag immediately when cancelTask is called, before calling abortTask()
2. Checking the abort flag in the stream error handler before calling abortTask() to preserve the original cancel source
3. Preventing redundant abort flag setting in the abortTask() method to avoid overwriting the original abort source

Changes Made

• src/core/webview/ClineProvider.ts: Set abort flag immediately when cancel is clicked
• src/core/task/Task.ts:
  • Check abort flag before calling abortTask() in stream error handler
  • Only set abort flag in abortTask() if not already set

Testing

• All existing tests pass
• Type checking passes
• Linting passes

Related Issues

Fixes #7014

---

Important

Fixes race condition in Task.ts to ensure cancel button properly stops streaming responses by setting and checking abort flag correctly.

• Behavior:
  • Fixes race condition where cancel button did not stop streaming responses in Task.ts.
  • Sets abort flag immediately when cancelTask is called in ClineProvider.ts.
  • Checks abort flag in stream error handler before calling abortTask() in Task.ts.
• Code Changes:
  • Task.ts:
    • Moves abort check before processing stream chunks.
    • Prevents redundant abort flag setting in abortTask().
• Testing:
  • All existing tests pass.
  • Type checking and linting pass.

^{This description was created by for 84f7196. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

I reviewed my own code and found it lacking in several dimensions, yet somehow it still works.

[roomote]

Is this intentional? You're setting cline.abort = true directly, then calling abortTask() which checks and potentially sets it again. While this works due to your guard clause, could we consider whether abortTask() could handle this internally with a parameter like abortTask(preserveOriginalSource = true) to make the intent clearer?

[roomote]

The comment could be more specific about what we're preserving. Consider:

Suggested change

	// Only set abort if not already set (to preserve the original abort source)
	// Only set abort if not already set (to preserve whether cancellation was user-initiated vs streaming failure)

[roomote]

Good defensive check here! This prevents the race condition where we'd incorrectly identify a user cancellation as a streaming failure. The logic flow is now: check existing abort state → determine cancel reason → conditionally call abortTask. This ensures we preserve the original cancellation source.