feat: add cancel button for context condensing operation

[f14XuanLv]

Related GitHub Issue

Closes: #6926

Roo Code Task Context (Optional)

Description

This PR adds a cancel functionality for context condensing operations, addressing the issue where users couldn't interrupt long-running condensing processes.

Key implementation details:

• Added a cancel button (X icon) in the TaskHeader component that appears when isCondensing is true
• Implemented frontend-to-backend cancel message passing mechanism (cancelCondenseContext message type)
• Used AbortController API to gracefully cancel async stream operations
• Added abort signal checking in the condenseContext stream processing
• Properly distinguished between cancelled and failed operations in error handling
• Added internationalization support for all 18 supported languages

Test Procedure

Testing steps:

1. Accumulate enough messages in a chat conversation to trigger context condensing
2. When condensing starts, observe the cancel button (X icon) appears in TaskHeader
3. Click the cancel button
4. Verify the condensing operation stops immediately
5. Check that the UI properly reflects the cancelled state (condensing indicator disappears)
6. Confirm no error messages are shown and the conversation can continue normally

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

[Screenshot 1: Shows cancel button during condensing]

[Screenshot 2: State after clicking cancel]

Documentation Updates

• No documentation updates are required.

Additional Notes

This feature improves user experience, especially when dealing with large contexts. The cancellation operation uses the standard AbortController pattern, ensuring proper resource cleanup.

Update: Fixed test failures by adding the missing abortSignal parameter to summarizeConversation calls in sliding-window tests, and completed internationalization for all supported languages (18 languages total).

Update 2: Fixed missing condense_cancelled translation key in common.json files for all languages, addressing the issue identified by Roomote bot review.

Get in Touch

N/A - Available via GitHub @f14XuanLv

[roomote]

Thank you for your contribution! I've reviewed the changes and found that while the implementation is generally clean and follows good patterns, there are some critical issues that need attention before merging.

[roomote]

Critical Issue: The translation key is not defined in the i18n files. This will cause a runtime error when the cancellation occurs.

You need to add this key to under the section:

Also add translations for other supported languages.

[roomote]

Good use of AbortController pattern for cancellation! The implementation is clean and follows best practices for handling async cancellation.

[roomote]

Consider adding proper TypeScript types instead of using type assertions. You could extend the Task interface to include these properties:

[roomote]

The type assertions here and should be replaced with proper TypeScript interfaces. This would improve type safety and make the code more maintainable.

[roomote]

Good addition of the English translation! However, you should also add this translation key to all other supported language files to maintain complete i18n coverage.

[roomote]

Good state management for the condensing operation. The UI properly reflects the condensing state and handles the cancellation cleanly.

[daniel-lxs]

Hey @f14XuanLv, I've been testing the cancel functionality and noticed a couple of issues:

1. The condensing cooldown seems to be broken - I can trigger condensing multiple times in a row even though there's supposed to be a limit that prevents condensing if one happened recently.

2. There's a weird bug with the cancel button - if I click condense, then cancel, then try to condense again, I get an error saying "Failed to condense, condense was cancelled" even though I'm trying to start a fresh condensing operation. Seems like the abort controller state might not be getting cleaned up properly?

I pushed a fix for the TypeScript type assertions to your branch, but these functional issues should probably be addressed before merging. The cancel state might need to be reset more thoroughly when starting a new condensing operation.

[f14XuanLv]

Hey @daniel-lxs

Thanks for the detailed feedback! I've addressed both issues you mentioned:

Fixed Issues

1. Condensing cooldown mechanism ✅

Added concurrency control check to prevent multiple condensing operations from running simultaneously:

if (this.isCondensing) {
    console.warn("Context condensing is already in progress")
    return
}

2. Cancel state cleanup ✅

Added intelligent cleanup waiting mechanism to avoid race conditions:

if (this.condensingAbortController && this.condensingAbortController.signal.aborted) {
    await new Promise(resolve => setTimeout(resolve, 100))
}

✅ Testing Results

Verified through actual testing:

• Cancel functionality: Clicking cancel button immediately stops condensing operation ✅
• Concurrency control: Additional clicks during condensing are properly ignored ✅
• State cleanup: After cancellation, there's ~5 second cooldown period, then condensing works normally ✅

Ready for re-review!

[daniel-lxs]

Hey @f14XuanLv there's some logic that prevents frequent condesing:

This is not possible on the current version but seems possible on this PR, can you take a look?

[f14XuanLv]

Hi @daniel-lxs

I need some clarification on a few points:

1. Version Reference Ambiguity:
   When you say "there's some logic that prevents frequent condensing," which version are you referring to? Are you saying:

• The current version HAS this prevention logic, or
• My PR HAS this prevention logic?

2. Screenshot Source:
   Is the screenshot showing behavior from the current version or from my PR version?

3. Testing Methodology:
   I'm curious about how you managed to trigger two condensing operations so quickly. In my testing, condensing operations typically take much longer than a few seconds to complete. Are you using a special testing environment, or did you encounter a specific scenario that allows rapid consecutive condensing? I haven't experienced cases where condensing completes within 5 seconds.

Understanding these details will help me better identify and fix the problem you've found.

Thanks for your patience!

[hannesrudolph]

Moving to dans column so he answers

[daniel-lxs]

Hi @f14XuanLv - quick clarification:

1. Version reference: the cooldown logic exists on main today. This PR bypasses it, so condense can be re-triggered within the cooldown window.

2. Screenshot: it is demonstrating the behavior on this PR build (multiple back-to-back condenses within the cooldown window). On main this is blocked by the cooldown.

3. Repro (no special env):

• Let one condense finish, then click Condense again immediately (within the cooldown window).
  • On main: blocked by cooldown.
  • On this PR: starts a new condense (cooldown not enforced).
• Also: Start condense -> Cancel -> immediately click Condense again.
  • On main: blocked by cooldown.
  • On this PR: it starts right away and sometimes shows "Failed to condense, condense was cancelled", which suggests abort state and/or cooldown state is not reset consistently.

Important: concurrency is not the same as cooldown. An isCondensing guard only prevents overlap while one is running; we also need the time-based guard after a condense completes or is cancelled. The PR appears to short-circuit that check.

What to update:

• Reapply the cooldown check at the start of a condense attempt based on the last-completed-at timestamp (set it on both success and cancel).
• Ensure the abort controller is fully replaced before starting a new run, and that cancellation also sets last-completed-at so the cooldown still applies.

Once these are in, I can re-test.

[f14XuanLv]

@hannesrudolph Could you please move this to dan's column so he can answer these questions?

---

Hi @daniel-lxs,

Thank you for the clarification. However, I'm confused about your statement regarding the existing cooldown logic on main.

Current Analysis on main branch (commit: 87d50a7)

After examining the codebase on the latest main branch (commit 87d50a78cb92ab5f050a4ec1233afe7004a52e3c), I can only find message-based prevention logic, not time-based cooldown logic:

1. Message-based prevention in src/core/condense/index.ts:119-124:

const keepMessages = messages.slice(-N_MESSAGES_TO_KEEP)  // Last 3 messages
const recentSummaryExists = keepMessages.some((message) => message.isSummary)
if (recentSummaryExists) {
    const error = t("common:errors.condensed_recently")
    return { ...response, error }
}

2. The time-related logic I found is in Task.ts for general API rate limiting:

private static lastGlobalApiRequestTime?: number
// Used for general API rate limiting, not specifically for condensing

My Questions:

1. Could you please point me to the specific file and code location where this time-based cooldown logic exists on main (commit 87d50a78c)?
2. What is the default cooldown window duration?
3. Where is the "last-completed-at timestamp" being tracked that you mentioned?

I want to ensure I'm addressing the right issue, but I cannot locate the time-based cooldown mechanism you're referring to. It's possible I'm missing something, so your guidance on the specific location would be very helpful.

Regarding the reproduction steps:

The behavior you described (immediate re-triggering after completion/cancellation) might be related to the concurrent execution guard (isCondensing) rather than a time-based cooldown, which could explain why my changes affect it.

Could you help me identify where this time-based cooldown logic is implemented on main? This will help me preserve it properly in my PR.

Thanks for your patience!

[daniel-lxs]

Thanks for working on this! I'm closing this PR as part of cleanup for inactive PRs. The implementation would need some additional backend wiring to fully support the cancellation flow. If you'd like to revisit this feature, feel free to open a new PR or let me know if you want to continue with this one.