fix: 🐛 Remove all history when a user request is cancelled

[chezsmithy]

Description

Updated clearLastEmptyResponse to fully remove all history up until the last user message. This cleans up any dangling thinking, or tools use messages that may have been sent when the cancel button is used.

This should resolve any issues where dangling thinking or tools use messages are left behind when the cancel button is used breaking the ability to continue the session.

TODO: I discovered one edge case that I could use help fixing. When a file is edited there is a small window between when the edit is started and the editor displays the edits, Accept and Reject Buttons where the request can be cancelled. In this case the cancel button can leave things in an odd state with code still highlighted and the Accept / Reject buttons left behind. I wasn't sure how to check if we are in that state, and fully cancel the Edit Session. Effectively, I would like to perform he same operations as clicking the Reject Button. (Remove decorations, and cancel the edit session).

A potential solution could be disabling the cancel button during this small window while the IDE is being updated.

Checklist

• I've read the contributing guide
• The relevant docs, if any, have been updated or created
• The relevant tests, if any, have been updated or created

Screenshots

[ For visual changes, include screenshots. Screen recordings are particularly helpful, and appreciated! ]

Testing instructions

Enable Thinking
In Agent Mode:

1. Ask to update test.js and add a power function.
2. When thinking is displayed hit cancel.
3. Observe that thinking is removed, and you are retunred to the previous command.

In Agent Mode:

1. Ask to update test.js and add a power function.
2. Once thinking ends, and the LLM is starting to stream the next steps hit cancel.
3. Observe the edit step is stopped, and the thinking modes are cancelled.

Outcomes:

• All steps after the last user message should be removed from the UI and the messages should be removed from history. Tool calls in progress should be stopped.

---

Summary by mrge

Cancelling a user request now removes all history after the last user message, cleaning up any leftover thinking or tool messages.

• Bug Fixes
  • Fixed an issue where cancelling could leave dangling messages or incomplete tool states in the UI.

[netlify]

✅ Deploy Preview for continuedev canceled.

Name	Link
🔨 Latest commit	18c76d2
🔍 Latest deploy log	https://app.netlify.com/sites/continuedev/deploys/682445b2e0d3990008174413

[chezsmithy]

This TODO was on the mark. I've followed up with an implementation that follows this line of thinking and peformed extensive testing to validate it.

[RomneyDa]

@chezsmithy this will be a great problem to solve, has been on my mind recently.

The main issue and reason I hadn't approached this yet is that (correct me if I'm wrong) if the user cancels streaming in Agent mode with this implementation after several turns of the conversation, there will be no recent user messages and it will essentially truncate to the beginning of the convo since the pattern is
user -> assistant + calls -> tool -> assistant + calls -> tool -> assistant + calls etc.

In this case we also can't just truncate back to the last tool message because (if I remember right) e.g. Anthropic won't accept the handshake user -> assistant + calls -> tool (= user in anthropic/gemini) -> user because of sequential user messages

Would love ideas/brainstorming on how to solve this!

[chezsmithy]

@RomneyDa I ran a number of scenarios last night, and I agree with your assessment. There really isn't a good way to roll back to a point in time and keep all the call data balanced to avoid failures with the next API call.

I've seen other tools handle this differently with checkpoints that allow you to restore artifact state but do not modify the history and do not allow a cancel option.

Typically the loss of context from the last user message seems to be pretty short. The biggest loss can be tool outcome state. Perhaps there is a way to summarize those lost outcomes and inject that into the next user message, or maybe provide that as an option for the user? (E.g You are restarting a cancelled flow, would you like for me to include a summary of your cancelled tool calls into the next request?).

[chezsmithy]

Another thought.

Maybe we have adaptive cancel.

If you cancel a thinking call or LLM request after a user message, it rolls to the last user message.

If you cancel during a tools call it only cancels the call but doesn't roll back. Perhaps if a tools call has occurred since the last user message we never allow roll back, only cancelling the next tool call.