Bug: Race condition when cancelling task can corrupt conversation history

[KJ7LNW]

Version: v3.22.5
API Provider: anthropic
Model: sonnet-3.5

What happened?

Clicking the 'cancel' button while the model is responding can cause a race condition between an open and closed task while it tries to write. If the in-memory state is empty after cancelling, safeWriteJson will be given '[]' to write and clobber the file.

This results in the following error:

ERR [Extension Host] [Roo-Debug] readApiMessages: Found API conversation history file, 
but it's empty (parsed as []). TaskId: 68d5b8fb-1a53-45dd-9bf2-24934374293d, 
Path: /home/ewheeler/.config/Code - Insiders/User/globalStorage/rooveterinaryinc.roo-cline/tasks/68d5b8fb-1a53-45dd-9bf2-24934374293d/api_conversation_history.json

Once this happens, the user cannot type into the chat box without closing the task and reopening it.

Expected behavior

Cancelling a task should properly handle the race condition and not corrupt the conversation history file.

Steps to reproduce

1. Start a task with the model
2. While the model is responding (particularly during the 'thinking' phase)
3. Click the 'cancel' button
4. Observe that the task may hang and the chat box becomes unusable
5. Check the logs for the empty conversation history error

Additional context

Suggested fix: Use safeWriteJson read-modify-write transactions from PR #5332 for files in GlobalFileNames to prevent file corruption during race conditions.

[KJ7LNW]

@hannesrudolph - has been approved?

[KJ7LNW]

Technical Analysis: Read-Modify-Write (RMW) for Large JSON Files

This analysis details the technical plan for mitigating data loss risks associated with large JSON state files, covering both ui_messages.json and api_conversation_history.json.

1. Problem Statement

Several functions, most notably overwriteClineMessages and overwriteApiConversationHistory, perform non-atomic read-modify-write cycles. User actions like message deletion or checkpoint restoration trigger these functions, creating significant risk for both UI message history and the underlying API conversation history.

• Data Loss: Accidental or erroneous operations can truncate large JSON files, leading to irreversible loss of critical conversation data.
• Race Conditions: Concurrent file access without proper locking can lead to data corruption in either state file.
• Transaction Failures: A crash or error during the write process can leave files in a corrupted, unreadable state.

The fundamental issue is that the application reads a file into memory, modifies the data array, and then overwrites the original file without guarantees of atomicity or data integrity.

2. Proposed Solution: Enforce Atomic RMW Transactions

The recommended solution is to refactor all manual RMW cycles to use the existing safeWriteJson utility, which provides the necessary safety guarantees for a file-based transaction.

The safeWriteJson function supports a readModifyFn parameter. This callback function allows modification logic to be executed within a transaction that ensures:

• Locking: Prevents concurrent write operations.
• Atomicity: Uses temporary files and atomic rename operations, ensuring the original file is only replaced upon successful completion of the entire process.
• Rollback: Automatically restores the original file from a backup if any step in the transaction fails.

3. Implementation Plan

The plan is to systematically replace direct file modification logic with calls to safeWriteJson using its readModifyFn for all at-risk operations on both history files.

1. Create two new methods in Task.ts:

   • A method tentatively named modifyClineMessages to serve as the single, safe entry point for all modifications to ui_messages.json.
   • A method tentatively named modifyApiConversationHistory to serve as the single, safe entry point for all modifications to api_conversation_history.json.

2. Each new method will wrap its entire operation in a safeWriteJson call. The modification logic (such as slicing the respective message array) will be passed as the readModifyFn callback.

3. By doing this, the critical modification logic for each file is executed securely within its own safeWriteJson transactional context.

4. All existing call sites that currently perform dangerous, direct manipulations—such as those in webviewMessageHandler.ts and checkpoints/index.ts—will be refactored to use these new, safe methods for their respective data types.

This unified approach ensures that high-risk operations on both ui_messages.json and api_conversation_history.json are executed atomically and safely, preventing data corruption and loss.