feat: add tool call cancellation

[louis-jan]

Describe Your Changes

This PR implements tool call cancellation functionality, allowing users to cancel running MCP tool calls mid-execution.

CleanShot.2025-08-19.at.23.29.47.mp4

Backend (Rust/Tauri)

• Enhanced call_tool command with cancellation support via optional cancellation_token parameter
• New cancel_tool_call command to trigger cancellation of running tool calls
• Cancellation state management using HashMap<String, oneshot::Sender<()>> to track active tool calls
• Race condition handling using tokio::select! to manage timeout, tool execution, and cancellation signals

Frontend (TypeScript/React)

• Refactored callToolWithCancellation service to replace the original callTool, returning both promise and cancel function
• Enhanced useAppState hook with cancelToolCall function and setCancelToolCall method for state management
• Updated completion.ts to use the new cancellation-aware tool calling system
• Integrated stop functionality in ChatInput component to cancel tool calls when user stops generation

Fixes Issues

• Closes feat: Ability to Cancel Tool Calls Mid-Run #5792

Self Checklist

• Added relevant comments, esp in complex areas
• Updated docs (for bug fixes / features)
• Created issues for follow-up changes or refactoring needed

---

Important

Add tool call cancellation feature allowing users to cancel ongoing tool calls in both backend and frontend.

• Backend (Rust/Tauri):
  • Add cancel_tool_call command in commands.rs to cancel running tool calls using a cancellation token.
  • Modify call_tool in commands.rs to support cancellation via tokio::select! and oneshot::channel.
  • Manage cancellation state with tool_call_cancellations in state.rs.
• Frontend (TypeScript/React):
  • Refactor callToolWithCancellation in mcp.ts to return a promise and cancel function.
  • Update useAppState in useAppState.ts to include cancelToolCall and setCancelToolCall.
  • Integrate cancellation in ChatInput.tsx to stop tool calls when user stops generation.
• Misc:
  • Add cancelToolCall to AppRoutes in service.ts.

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

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 91f05b8 in 2 minutes and 31 seconds. Click for details.

• Reviewed 341 lines of code in 8 files
• Skipped 0 files when reviewing.
• Skipped posting 5 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. src-tauri/src/core/mcp/commands.rs:265

• Draft comment:
  If no matching tool is found, the cancellation token (if provided) isn’t removed from the state, which may lead to a memory leak. Consider cleaning up the token before returning the error.
• Reason this comment was not posted:
  Comment was on unchanged code.

2. src-tauri/src/core/mcp/commands.rs:230

• Draft comment:
  Good use of tokio::select! to race between the tool call, timeout, and cancellation signal. This concurrency control is clear and robust.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

3. web-app/src/containers/ChatInput.tsx:166

• Draft comment:
  The stopStreaming callback now calls cancelToolCall in addition to aborting. Ensure that after a tool cancellation, the global cancelToolCall function is reset to prevent reuse or stale cancellations.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment makes a speculative suggestion about state management that we can't verify from this file alone. We don't know if cancelToolCall already handles its own cleanup, or if it even needs to be reset. The comment is asking the author to "ensure" something without clear evidence of an actual issue. The comment could be pointing to a real issue with stale cancellation state. Without seeing the implementation of cancelToolCall, I can't be 100% certain this isn't a valid concern. However, this is exactly the kind of speculative comment we should avoid - it's asking the author to verify/ensure something without clear evidence of a problem. The cancelToolCall function likely handles its own state management. Delete this comment. It's speculative and asks for verification without evidence of an actual issue. If there were a real problem with stale cancellation state, it should be handled in the cancelToolCall implementation.

4. web-app/src/lib/completion.ts:385

• Draft comment:
  Storing the cancel function in the global app state via setCancelToolCall is a neat approach; however, ensure that subsequent tool invocations overwrite or clear stale cancel functions to avoid accidental cancellations.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

5. web-app/src/services/mcp.ts:75

• Draft comment:
  The enhanced callToolWithCancellation function correctly generates a unique cancellation token and returns a cancel function. Consider adding a safeguard in case window.core?.api is undefined, to ensure robust error handling in environments where the core API might not be available.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The code already uses optional chaining which handles undefined cases gracefully. This is consistent with the pattern used throughout the file. The comment seems to suggest additional error handling but doesn't specify what exactly should be done differently. The current approach appears intentional and consistent. Maybe there could be edge cases where more explicit error handling would be helpful? The promise might resolve to undefined which could cause issues downstream. The code follows the established pattern in the codebase. If undefined handling was an issue, it would affect all functions equally and should be addressed at a higher level, not just this function. The comment should be deleted as it suggests changing established patterns without clear justification or specific actionable improvements.

Workflow ID: wflow_UEeAPlWdfhGBYEAc

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[github-actions]

Barecheck - Code coverage report

Total: 37.57%

Your code coverage diff: -0.01% ▾

Uncovered files and lines

File	Lines
web-app/src/containers/ChatInput.tsx	86-88, 108-109, 117-118, 145-146, 168-170, 177-178, 181-184, 187-199, 202, 204-206, 212, 214, 216-217, 219-223, 226-227, 230-235, 237-240, 242-246, 248-260, 262-272, 274-283, 285-288, 318-326, 328-333, 335-352, 354-356, 358-360, 362-363, 414, 453-467, 484-486, 491-495, 510-514, 529-543, 546-560, 570, 584, 600, 602-605
web-app/src/hooks/useAppState.ts	57, 95-98, 119-122
web-app/src/lib/completion.ts	131-139, 141, 143-144, 146-147, 149, 151, 154-160, 162-164, 166-170, 172-173, 176-184, 186, 188-203, 205-226, 242-248, 299, 302-307, 309-312, 328-333, 338-339, 341-363, 366-383, 385-390, 392, 394-414, 416-425, 427-441, 443-446
web-app/src/lib/service.ts	1-2, 4-26, 28-31, 34-36, 38-42, 44-52
web-app/src/services/mcp.ts	74, 76, 79-82, 85-87, 89-90, 98-99