[BUG] Parent tasks disappear from history when files temporarily unavailable, orphaning child tasks

[SannidhyaSah]

Problem (one or two sentences)

Parent tasks in delegation chains (Orchestrator mode and subtasks) are being permanently deleted from task history when their api_conversation_history.json file is temporarily unavailable, causing child tasks to become orphaned and unable to navigate back to their parent.

Context (who is affected and when)

This affects users who:

• Use Orchestrator mode to delegate tasks to child modes
• Create long chains of subtasks (A → B → C)
• Try to navigate back to a parent task using the "Back to Parent Task" button
• Have slow disk I/O or filesystem latency

The issue is particularly severe during delegation transitions when parent tasks are disposed and child tasks are created, creating a race condition window.

Reproduction steps

1. Environment/setup:

   • Any OS with Roo Code extension
   • Any API provider
   • Use Orchestrator mode or any mode that delegates tasks via new_task tool

2. Exact actions:

   • Start a parent task in Orchestrator mode
   • Let it create a subtask (delegation)
   • While subtask is running, if any file I/O latency occurs:
     • Or manually: delete/rename the parent's api_conversation_history.json file in global storage
   • Click "Back to Parent Task" button in the subtask
   • Or wait for subtask to complete and auto-resume parent

3. What you observed:

   • Parent task entry disappears from task history completely
   • Child task shows "Back to Parent Task" button but clicking it fails
   • Error "Task not found" is thrown
   • In longer chains (A→B→C), completing C may orphan B, then A becomes unreachable

Expected result

Parent tasks should remain in task history even if their files are temporarily unavailable. Navigation should either retry, show an error without deleting data, or gracefully handle the missing file scenario.

Actual result

Parent tasks are permanently deleted from taskHistory global state when getTaskWithId() is called and the api_conversation_history.json file doesn't exist. This happens via deleteTaskFromState() being called unconditionally when files are missing.

Variations tried (optional)

This is a code analysis finding. The vulnerable code path is:

• src/core/webview/ClineProvider.ts lines 1658-1693 (getTaskWithId())
• The code includes a // FIXME comment acknowledging the issue: "this seems to happen sometimes when the json file doesnt save to disk for some reason"

Related vulnerable paths include:

• showTaskWithId() - Navigation triggers the deletion
• reopenParentFromDelegation() - Delegation resume can trigger deletion
• deleteTaskWithId() - Cascading deletions can occur

App Version

Any version with the current getTaskWithId() implementation (verified in current main)

API Provider

Not Applicable / Other (affects all providers)

Additional Technical Context

Root cause location: getTaskWithId() in src/core/webview/ClineProvider.ts (lines 1658-1693)

// If task exists in history but file is missing, it gets DELETED:
await this.deleteTaskFromState(id)  // Line 1691
throw new Error("Task not found")   // Line 1692

Impact severity: High - Data loss, broken navigation, orphaned tasks

Related metadata fields in HistoryItem:

• parentTaskId - becomes a dangling reference when parent is deleted
• childIds - parent loses track of children if deleted
• awaitingChildId, delegatedToId, completedByChildId - all become invalid

Key code paths affected:

1. getTaskWithId() - Primary bug location
2. showTaskWithId() - UI navigation triggers deletion
3. reopenParentFromDelegation() - Auto-resume can fail and delete parent
4. delegateParentAndOpenChild() - Race window during delegation
5. deleteTaskWithId() - Cascading effects when orphan detection fails

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause Analysis

The bug is in getTaskWithId() (src/core/webview/ClineProvider.ts, lines 1658-1693). When a task exists in the taskHistory state but its api_conversation_history.json file is missing (temporarily or otherwise), the code unconditionally deletes the task from state:

// FIXME: this seems to happen sometimes when the json file doesnt save to disk for some reason
await this.deleteTaskFromState(id)
throw new Error("Task not found")

This is problematic because:

1. Files can be temporarily unavailable due to disk I/O latency or race conditions during delegation transitions
2. Parent tasks have critical metadata (parentTaskId, childIds, delegatedToId, awaitingChildId) linking them to children
3. Deleting a parent task orphans all children and breaks navigation

Proposed Solution

1. Remove the destructive deleteTaskFromState() call from getTaskWithId()

Instead of deleting the task when the file is missing, throw an error without modifying state. The task metadata in history remains intact.

2. Create a new error class TaskFileMissingError

This allows callers to distinguish between:

• Task doesn't exist in history at all (Task not found)
• Task exists in history but file is temporarily unavailable (TaskFileMissingError)

3. Add optional retry logic with exponential backoff

For transient file system issues, add a small retry mechanism (e.g., 2-3 retries with 100-200ms delays) before giving up.

4. Update affected callers to handle the new error appropriately

Methods like showTaskWithId(), reopenParentFromDelegation(), and deleteTaskWithId() should:

• For navigation/viewing: Show a user-friendly error message instead of deleting data
• For deletion: Keep existing behavior (already handles "Task not found" gracefully)
• For delegation resume: Retry or show error, but never delete the parent

5. Add safeguard for tasks with delegation metadata

Tasks that have parentTaskId or childIds should NEVER be auto-deleted, as they are part of a delegation chain.

Code Changes Summary

• src/core/webview/ClineProvider.ts:
  • Modify getTaskWithId() to remove deleteTaskFromState() call
  • Add TaskFileMissingError error class
  • Add optional retry logic for file reads
  • Update callers to handle new error appropriately
• Add tests to verify:
  • Tasks are not deleted when files are temporarily unavailable
  • Delegation chains remain intact even with missing files
  • Proper error handling and user feedback

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

[SannidhyaSah]

Detailed Technical Analysis & Suggested Fixes

Primary Vulnerability: Destructive Error Handling in getTaskWithId()

Location: src/core/webview/ClineProvider.ts lines 1658-1693

Current problematic code:

async getTaskWithId(id: string): Promise<...> {
    const history = this.getGlobalState("taskHistory") ?? []
    const historyItem = history.find((item) => item.id === id)

    if (historyItem) {
        const taskDirPath = await getTaskDirectoryPath(globalStoragePath, id)
        const apiConversationHistoryFilePath = path.join(taskDirPath, GlobalFileNames.apiConversationHistory)
        const fileExists = await fileExistsAtPath(apiConversationHistoryFilePath)

        if (fileExists) {
            // ... return task data (happy path)
        }
    }

    // DESTRUCTIVE: Deletes task from state if file is missing
    await this.deleteTaskFromState(id)
    throw new Error("Task not found")
}

The bug: The function conflates "task doesn't exist" with "task's file is temporarily unavailable", then permanently deletes the task metadata from global state.

---

Suggested Fix #1: Remove Destructive Auto-Deletion

async getTaskWithId(id: string): Promise<...> {
    const history = this.getGlobalState("taskHistory") ?? []
    const historyItem = history.find((item) => item.id === id)

    if (!historyItem) {
        // Task truly doesn't exist in history
        throw new Error(`Task ${id} not found in history`)
    }

    const taskDirPath = await getTaskDirectoryPath(globalStoragePath, id)
    const apiConversationHistoryFilePath = path.join(taskDirPath, GlobalFileNames.apiConversationHistory)
    const fileExists = await fileExistsAtPath(apiConversationHistoryFilePath)

    if (!fileExists) {
        // File is missing but task metadata exists - DON'T delete!
        // Option A: Return partial data
        return {
            historyItem,
            taskDirPath,
            apiConversationHistoryFilePath,
            uiMessagesFilePath: path.join(taskDirPath, GlobalFileNames.uiMessages),
            apiConversationHistory: [], // Empty but recoverable
        }
        // Option B: Throw specific error for caller to handle
        // throw new TaskFilesMissingError(id, historyItem)
    }

    // ... normal return
}

---

Suggested Fix #2: Add Retry Logic with Exponential Backoff

async getTaskWithId(id: string, options?: { retries?: number }): Promise<...> {
    const maxRetries = options?.retries ?? 3
    const retryDelayMs = 100

    for (let attempt = 0; attempt < maxRetries; attempt++) {
        const fileExists = await fileExistsAtPath(apiConversationHistoryFilePath)
        if (fileExists) {
            // Success - return data
            break
        }
        if (attempt < maxRetries - 1) {
            await new Promise(resolve => setTimeout(resolve, retryDelayMs * Math.pow(2, attempt)))
        }
    }
    // After retries, still don't delete - just report the issue
}

---

Suggested Fix #3: Add Referential Integrity Check Before Deletion

async deleteTaskFromState(id: string) {
    const taskHistory = this.getGlobalState("taskHistory") ?? []
    
    // Check for referential integrity violations
    const hasChildReferences = taskHistory.some(task => task.parentTaskId === id)
    const hasParentReferences = taskHistory.some(task => task.childIds?.includes(id))
    
    if (hasChildReferences || hasParentReferences) {
        console.warn(`[deleteTaskFromState] Refusing to delete task ${id} - has active references`)
        return // Don't delete tasks that are part of a chain
    }
    
    // Proceed with deletion only if no references exist
    const updatedTaskHistory = taskHistory.filter((task) => task.id !== id)
    await this.updateGlobalState("taskHistory", updatedTaskHistory)
}

---

🔴 Additional Vulnerabilities Found

Vulnerability #2: Race Condition in delegateParentAndOpenChild()

Location: src/core/webview/ClineProvider.ts lines 3151-3256

Issue: Parent task is disposed BEFORE child task files are fully written:

// Line 3195: Parent disposed first
await this.removeClineFromStack()

// Line 3223: Child created after - but what if this fails?
const child = await this.createTask(message, undefined, parent as any, {...})

// If createTask fails, parent is already gone with no recovery

Suggested Fix: Use a transaction-like pattern:

async delegateParentAndOpenChild(params) {
    // 1. Create child FIRST (but don't activate)
    const child = await this.createTask(..., { startTask: false })
    
    // 2. Only dispose parent after child is confirmed created
    await this.removeClineFromStack()
    
    // 3. Now activate child
    await child.start()
}

---

Vulnerability #3: Missing File Write Synchronization

Location: src/core/task-persistence/apiMessages.ts

Issue: saveApiMessages() uses async file write but callers don't always await completion before triggering reads.

Evidence: In reopenParentFromDelegation() (line 3380):

await saveApiMessages({ messages: parentApiMessages, taskId: parentTaskId, ... })
// Immediately after, other code might call getTaskWithId() before disk flush

Suggested Fix: Add write confirmation or use synchronous writes for critical operations:

async saveApiMessages({ messages, taskId, globalStoragePath }) {
    const filePath = path.join(taskDir, GlobalFileNames.apiConversationHistory)
    await safeWriteJson(filePath, messages)
    
    // Verify write completed
    const written = await fileExistsAtPath(filePath)
    if (!written) {
        throw new Error(`Failed to persist API messages for task ${taskId}`)
    }
}

---

Vulnerability #4: Cascading Deletion Without Orphan Protection

Location: src/core/webview/ClineProvider.ts lines 1749-1830 (deleteTaskWithId())

Issue: When deleting a task with cascadeSubtasks: true, if the parent deletion succeeds but a child deletion fails, the state becomes inconsistent.

// Line 1788-1791: All tasks removed from state in one batch
const updatedTaskHistory = taskHistory.filter((task) => !allIdsToDelete.includes(task.id))
await this.updateGlobalState("taskHistory", updatedTaskHistory)

// Line 1800-1818: File deletions happen AFTER state update
// If these fail, state and disk are out of sync

Suggested Fix: Delete files first, then update state:

async deleteTaskWithId(id: string, cascadeSubtasks = true) {
    // 1. Collect all IDs to delete
    const allIdsToDelete = [id, ...(cascadeSubtasks ? await this.collectChildIds(id) : [])]
    
    // 2. Delete files FIRST (can be recovered from state if this fails)
    for (const taskId of allIdsToDelete) {
        try {
            await this.deleteTaskFiles(taskId)
        } catch (e) {
            console.warn(`Failed to delete files for ${taskId}, continuing...`)
        }
    }
    
    // 3. Update state LAST (atomic operation)
    const taskHistory = this.getGlobalState("taskHistory") ?? []
    const updatedTaskHistory = taskHistory.filter((task) => !allIdsToDelete.includes(task.id))
    await this.updateGlobalState("taskHistory", updatedTaskHistory)
}

---

Vulnerability #5: No Soft-Delete or Recovery Mechanism

Issue: Once deleteTaskFromState() is called, the task is permanently gone. There's no:

• Soft-delete with recovery period
• Trash/recycle bin for accidentally deleted tasks
• Undo mechanism

Suggested Fix: Implement soft-delete:

const historyItemSchema = z.object({
    // ... existing fields
    deletedAt: z.number().optional(), // Timestamp of soft-delete
})

async deleteTaskFromState(id: string) {
    const taskHistory = this.getGlobalState("taskHistory") ?? []
    const taskIndex = taskHistory.findIndex((task) => task.id === id)
    
    if (taskIndex !== -1) {
        // Soft-delete: mark as deleted instead of removing
        taskHistory[taskIndex].deletedAt = Date.now()
        await this.updateGlobalState("taskHistory", taskHistory)
    }
}

// Separate cleanup job to permanently delete after N days
async cleanupDeletedTasks(olderThanDays = 7) {
    const cutoffTime = Date.now() - (olderThanDays * 24 * 60 * 60 * 1000)
    const taskHistory = this.getGlobalState("taskHistory") ?? []
    const filtered = taskHistory.filter(task => 
        !task.deletedAt || task.deletedAt > cutoffTime
    )
    await this.updateGlobalState("taskHistory", filtered)
}

---

Vulnerability #6: UI Navigation Can Trigger Data Loss

Location: webview-ui/src/components/chat/TaskHeader.tsx line 147-150

Issue: The "Back to Parent Task" button directly calls showTaskWithId() which eventually calls getTaskWithId(), potentially triggering the destructive deletion:

const handleBackToParent = () => {
    if (parentTaskId) {
        vscode.postMessage({ type: "showTaskWithId", text: parentTaskId })
        // This can DELETE the parent task if its file is missing!
    }
}

Suggested Fix: Add error handling in the webview handler:

// In ClineProvider.ts setWebviewMessageListener()
case "showTaskWithId":
    try {
        await this.showTaskWithId(message.text)
    } catch (error) {
        if (error.message.includes("Task not found")) {
            // Show user-friendly error instead of silent deletion
            await this.postMessageToWebview({
                type: "error",
                message: `Task ${message.text} is no longer available. It may have been deleted or its files are missing.`
            })
        }
    }
    break

---

Recommended Implementation Priority

1. Critical (Immediate): Remove auto-deletion in getTaskWithId() - prevents further data loss
2. High: Add referential integrity checks before any deletion
3. Medium: Implement retry logic for file access
4. Medium: Add soft-delete mechanism
5. Low: Add transaction-like semantics for multi-task operations
6. Low: Improve error handling in UI navigation

---

Suggested Test Cases

1. Test: File temporarily unavailable during navigation

   • Create parent task, delegate to child
   • Temporarily rename parent's api_conversation_history.json
   • Click "Back to Parent Task"
   • Verify parent is NOT deleted from history

2. Test: Race condition during delegation

   • Add artificial delay in saveApiMessages()
   • Trigger rapid delegation
   • Verify no tasks are lost

3. Test: Referential integrity

   • Create task chain A→B→C
   • Try to delete B directly
   • Verify A and C remain intact with proper error

4. Test: Recovery from partial state

   • Create task with metadata but no files
   • Verify task can be recovered or properly handled

[SannidhyaSah]

@roomote I approve this plan. Please proceed with the implementation.

The analysis correctly identifies the root cause in getTaskWithId() and the proposed solution aligns with the comprehensive analysis above. Key priorities:

1. Critical: Remove the destructive deleteTaskFromState() call - this is the primary fix
2. High: Implement the TaskFileMissingError error class for proper error handling
3. Medium: Add retry logic with exponential backoff for transient file I/O issues
4. Important: Add safeguards for tasks with delegation metadata (parentTaskId, childIds) - these should never be auto-deleted

Please also consider the additional vulnerabilities documented in the detailed analysis above, particularly:

• The race condition in delegateParentAndOpenChild() where parent is disposed before child is confirmed
• Referential integrity checks before any deletion
• The cascading deletion issues in deleteTaskWithId()

Looking forward to the fix!

[roomote]

I've seen your approval and will proceed with the implementation. I'll explore the relevant code paths and implement the fix as discussed.

Key changes I'll be making:

1. Remove the destructive deleteTaskFromState() call from getTaskWithId()
2. Implement TaskFileMissingError error class for proper error handling
3. Add retry logic with exponential backoff for transient file I/O issues
4. Add safeguards for tasks with delegation metadata

I'll open a draft PR to share progress shortly.

[roomote]

I've opened a draft PR with my attempt at addressing this issue: #11173

Key changes:

1. Removed the destructive deleteTaskFromState() call from getTaskWithId() - the primary fix
2. Added TaskFileMissingError and TaskNotFoundError error classes for proper error handling
3. Added retry logic with exponential backoff (3 retries, 100-400ms delays) for transient file I/O issues
4. Updated callers (showTaskWithId(), deleteTaskWithId(), reopenParentFromDelegation()) to handle the new errors appropriately
5. Added hasDelegationMetadata flag to identify tasks in delegation chains that should never be auto-deleted

All tests pass (103 tests total, including 8 new tests for the error handling behavior).

Feedback welcome!