[Fix] Task history disappears when user reopens a task

[zoomote]

​Created by Roomote. Follow up by mentioning @roomote, in the web UI, or in Discord.

What changed

• Preserve finalized reasoning and other saved messages while a task is rehydrated for resume.
• Distinguish missing, invalid, and unreadable task history from an explicitly empty history instead of converting failures to an empty conversation.
• Retry a transient missing-file read once with jitter to bridge the safe-write rename window.
• Merge ordinary UI and API history snapshots under the existing advisory file lock so stale writers preserve newer disk messages.
• Keep explicit rewind, truncation, and overwrite operations authoritative rather than merging removed history back in.
• Stop abandoned history-task hydration before it can persist after eviction.
• Abort delegated-parent reopening when its saved UI history cannot be loaded safely.
• Add deterministic regression coverage for hydration failures, finalized reasoning, resume/eviction races, retry behavior, merge ordering, legacy histories, and tool call/result ordering.

Why this change was made

Reopening or quickly leaving a saved task could replace valid history with an empty or shortened message list. Concurrent extension instances could also overwrite a newer history suffix with a stale snapshot. This resolves#1279 and extends the lifecycle and persistence safety work tracked by #355, #208, and #1231.

Impact

Users keep their last saved task content when reopening or resuming tasks. Temporary storage gaps are retried, ordinary concurrent writes preserve newer messages, and stale task instances cannot write after being evicted. Explicit user-driven history rewinds continue to replace history as intended.

Related PRs

• Documentation: [Docs] Explain task history recovery safeguards Zoo-Code-Docs#40

[codecov]

Codecov Report

❌ Patch coverage is 97.58065% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/core/task-persistence/apiMessages.ts	96.66%	1 Missing ⚠️
.../core/task-persistence/readFileWithMissingRetry.ts	90.90%	0 Missing and 1 partial ⚠️
src/core/webview/ClineProvider.ts	80.00%	0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[martin-rueegg]

Looks like this might also contribute to fixing some of the things I've experienced in #1231, too

[martin-rueegg]

I think the fix is the right approach but can be strengthened by using the new merge functionality of the safeWriteJson() method and updating the local copy with the merged result.

@roomote

[zoomote]

Addressed the retry and merge feedback in 3f5b2d04:

• retries the safe-write ENOENT window once with 10–300 ms jitter;
• merges ordinary UI/API snapshots under the advisory lock while preserving authoritative rewinds;
• preserves equal timestamps, legacy ordering, completed/answered UI state, and API tool call/result order;
• adds focused coverage for retry, merge routing, second-stage abort, and delegated-parent read failure.

The full Zoo Code test suite passes (7,560 tests), and the previously uncovered Task/ClineProvider branches now have direct regression coverage. All three review threads were replied to and resolved.

[martin-rueegg]

I think we should write a wrdning. Although the data is migrated, a history file gets deleted. worth at least a warning in the log:

 console.warn(
`[readApiMessages] Found OLD API conversation history file (claude_messages.json): contained data was migrated to the new history and the file removed.`,
)

[martin-rueegg]

actually, the migration does NOT happen here. Only the file deleted after successful read. So where do they get merged or saved into the new message? - I only ever see saveApiMessages() called from tests, but not from live code. It's probably me, not seeing it ... ;-)

[edelauna]

Fixed in f402132: readApiMessages() now persists parsed legacy claude_messages.json history via safeWriteJson(..., { merge: mergeApiMessageSnapshots }) before deleting the legacy file. The regression test verifies persistence and cleanup ordering.

[martin-rueegg]

should this maybe default to undefined?

see comment line 40

[edelauna]

Fixed in f402132: mergeTimestampedSnapshots() now makes mergeMatch optional, so API snapshot merging no longer needs an identity callback.

[martin-rueegg]

see line 10

I think this line would be easier to understand if it would read:

if(mergeMatch!==undefined&&diskMessage!==undefined){returnmergeMatch(diskMessage,message)}returnmessage

rather then the same functionality being burried in mergeApiMessageSnapshots's (_disk, next) => next on line 84

[edelauna]

Fixed in f402132: mergeTimestampedSnapshots() now explicitly returns the incoming message when no callback or matching disk message exists, and mergeApiMessageSnapshots() calls it without (_disk, next) => next.