[BUG] After failed file edit loading icon still spinning

[CyberT33N]

Problem (one or two sentences)

@roomote

There are two things I noticed.

The first is that when editing a file fails, the spinner at the top, meaning the loading icon, remains active. It is hard to tell whether anything is still happening here.

I strongly assume this is just a UI bug: when the tool cannot write the file, caused by the LLM hallucinating during the freeform patch, or depending on how it calls the tool here, whether it is using freeform patch or working with lines, in any case, this is the standard issue that has always existed with edit tools. LLMs start hallucinating beyond a certain length and should really re-anchor beforehand.

The problem is that it simply keeps going, and the loading bar at the top remains active. It is difficult to say what exactly is happening here, because there is no error handling or anything similar in this regard. It just keeps loading.

However, I strongly assume that this is only a UI bug.

I was able to reproduce that, without my own system prompt that I set for my mode, this can happen up to four times in a row, to the point that it becomes unusable, until Roo Code eventually aborts after a certain minimum number of attempts because of the failure state it has built in.

That would be the second feature that would need to be integrated.

The system prompt that is currently set as the default for tool usage is simply phrased too loosely. This is the most important anchor point, because LLMs consistently hallucinate here.

Of course, it is fine to have a fallback so that it does not get stuck in an endless loop and stops after a certain number of failed attempts, and to have that option available. I do not want to argue against that. However, the core problem is the architectural system prompt.

From my own experience, I can say that this issue with these tools can be addressed architecturally through prompting by requiring a re-anchoring step before every edit to a file. In other words, a re-anchoring step must take place, and in addition there must be a multi-level evaluation principle for whatever is currently being patched.

That means:

• whether a full rewrite is being done,
• whether a sequential edit is being done,
• the size of what is currently being edited,
• and, for example, if only hypothetically 15% of the file is being edited, then a small sequential edit should be made,
• whereas if it is being edited more extensively, say 80%, then a full rewrite should be done.

At the same time, boundaries should also be set. For example, if the file is 1,200 characters long, then a full rewrite should not be the default, because proportionally, based on the weighting, the likelihood is simply higher that LLMs will hallucinate through the freeform patch.

On top of that, there are naturally also topics such as the context window here, how large it is, and if this is done properly at the architectural level, there is also access to the context size here, etc., so it would even be possible to handle this differently.

Either way, architecturally this can be solved in more than 80% of cases if a re-anchoring step is performed.

That means the option should be integrated that, although it is naturally more context-intensive in terms of token usage, a renewed re-anchoring step is always performed beforehand. There should be such an option in the settings.

If the option is enabled, the default system prompt should be extended so that a default re-anchoring step is always performed before any existing file is edited in any way, so that line-patch or freeform-patch errors are drastically reduced.

Context (who is affected and when)

see desc

Reproduction steps

see desc

Expected result

see desc

Actual result

see desc

Variations tried (optional)

No response

App Version

Version: 3.51.1 (7c9722b)

API Provider (optional)

None

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

I have analyzed this issue and here is my proposed implementation plan. The issue has two distinct parts:

Root Cause Analysis

Part 1: Spinner keeps spinning during failed file edits (UI bug)

The loading spinner in the UI is driven by the isStreaming computation in ChatView.tsx, which checks whether the last api_req_started message has a cost field set. When a file edit tool (e.g., apply_diff) fails:

1. During streaming, handlePartial() creates partial ask messages (with partial: true) to show tool progress in the UI.
2. When execute() runs and the diff fails (e.g., due to LLM hallucination), it calls pushToolResult(error) to feed the error back to the conversation -- but it does not call askApproval, which would normally resolve/close the partial ask message from step 1.
3. The partial ask message from handlePartial is left with partial: true in the messages array and is never properly closed.
4. On the first failure (consecutiveMistakeCount < 2), no user-visible error message is emitted at all -- no task.say("diff_error", ...) or task.say("error", ...) is called. The tool silently pushes an error result and the next API request begins immediately.
5. The user sees continuous spinning with no indication that edits are failing and being retried.

Part 2: Feature request for re-anchoring

The second part of the issue requests a "re-anchoring step" setting that would instruct the LLM to re-read the file before every edit. This is a larger feature request that involves prompt engineering and settings UI work.

Proposed Plan (scoped to the UI bug fix)

I propose to fix the UI bug (Part 1) as follows. The feature request (Part 2) can be addressed separately.

1. Always show diff_error message on first failure in ApplyDiffTool.execute()

File: src/core/tools/ApplyDiffTool.ts (lines 83-117)

Currently, task.say("diff_error", formattedError) is only called when currentCount >= 2. Change this to always call it on every failure, so the user gets immediate visual feedback that the edit failed:

// Before:
if (currentCount >= 2) {
    await task.say("diff_error", formattedError)
}

// After:
await task.say("diff_error", formattedError)

2. Close the partial ask message when tool execution fails in ApplyDiffTool.execute()

When the diff fails and no askApproval is called, the partial ask from handlePartial remains unclosed. Add cleanup to resolve it by calling task.finishPartialAsk() or updating the last partial message to partial: false before returning the error:

File: src/core/tools/ApplyDiffTool.ts

In the error path (around line 83), before pushToolResult(formattedError):

// Close any partial ask message left by handlePartial
const lastMessage = task.clineMessages.at(-1)
if (lastMessage && lastMessage.partial && lastMessage.type === "ask" && lastMessage.ask === "tool") {
    lastMessage.partial = false
    await task.saveClineMessages()
}

3. Apply the same fix pattern to other edit tools

The same pattern exists in WriteToFileTool.ts and EditFileTool.ts. Apply the same partial-close + error-visibility fixes to their failure paths for consistency.

4. Add/update tests

Add test coverage for the error paths in the affected tool files to verify that:

• Error messages are always surfaced to the user on first failure
• Partial ask messages are properly closed on tool failure

---

This approach is minimal and surgical -- it fixes the spinner stall and makes edit failures visible to the user without changing the retry logic or adding new settings.

Please mention @roomote in a comment saying that you approve this plan, and I will proceed with the implementation.

[CyberT33N]

@roomote

Yes, I agree with you. I want you to please fully implement Part 1 and Part 2; they MUST be completed 100%.

[roomote-v0]

I've seen your comment and will implement both Part 1 (UI bug fix for spinner on failed edits) and Part 2 (re-anchoring feature). I'll open a PR to share progress shortly.

[roomote-v0]

Opened a draft PR with my attempt at addressing both parts of this issue: #12033

Part 1 (UI bug fix): ApplyDiffTool now properly closes partial ask messages on error, stopping the stuck spinner. Both ApplyDiffTool and EditFileTool now show diff_error on every failure (not just the 2nd consecutive one).

Part 2 (Re-anchoring): Added a new experimental setting "Re-anchor before file edits" (off by default). When enabled, the system prompt instructs the model to always re-read a file before editing it, reducing hallucination-based edit failures.

Feedback welcome!