fix(task-history): route invalidate() and invalidateAll() through withLock

[morgan-coded]

Locks invalidate() and invalidateAll() behind TaskHistoryStore's existing withLock queue so cache invalidation cannot interleave with an in-flight mutation. Each method keeps its existing cache behavior.

Related GitHub Issue

Fixes #698

Description

Per your note, I routed invalidate() rather than removing it: the census found no non-test callers, but TaskHistoryStore is exported from the task-persistence barrel, so deleting its public method could break consumers.

Method	Definitions	Non-test callers	Test references	Export surface	Decision
invalidate()	1	0	3 call sites	Public method on the barrel-exported TaskHistoryStore	Route through withLock
invalidateAll()	1	1	6 mock/assertion references	Public method on the barrel-exported TaskHistoryStore	Route through withLock

Test Procedure

The regression blocks writeTaskFile with a manually controlled promise after the lock is acquired, calls invalidateAll(), then releases the write. It asserts that onWrite sees both cached tasks before the queued invalidation clears the final cache, so no timer or scheduling delay controls the result.

• pnpm --filter zoo-code exec vitest run core/task-persistence/__tests__/TaskHistoryStore.spec.ts
• pnpm test
• pnpm lint
• pnpm check-types

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue.
• Scope: The changes are focused on the linked issue.
• Self-Review: I performed a self-review of the cache and test changes.
• Testing: A deterministic concurrency regression covers the change.
• Documentation Impact: No user-facing documentation changes are required.
• Contribution Guidelines: I read and agree to the Contributor Guidelines.

Additional Notes

Non-goals: no other cache methods, lock implementation, callers, or APIs are changed.

Summary by CodeRabbit

• Bug Fixes
  • Prevented task history cache invalidation from interfering with concurrent updates by performing cache mutations under a write lock.
  • Ensured “import history” waits for cache invalidation to complete before reconciling and flushing the index.
• Tests
  • Added concurrency tests for invalidating individual tasks and clearing the cache during an in-progress update.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: da3d9dae-2b81-431f-a80b-13e1aeca1d09

📥 Commits

Reviewing files that changed from the base of the PR and between dd158bb and 38ae51e.

📒 Files selected for processing (3)

• src/core/task-persistence/TaskHistoryStore.ts
• src/core/task-persistence/__tests__/TaskHistoryStore.spec.ts
• src/core/webview/webviewMessageHandler.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• src/core/task-persistence/TaskHistoryStore.ts

---

📝 Walkthrough

Walkthrough

Task history invalidation now runs through the write lock. invalidateAll() is asynchronous, its caller awaits completion, and concurrency tests cover invalidation during ongoing writes.

Changes

Task history cache consistency

Layer / File(s)	Summary
Lock invalidation and validate concurrency src/core/task-persistence/TaskHistoryStore.ts, src/core/task-persistence/__tests__/TaskHistoryStore.spec.ts	invalidate() refreshes or removes entries under withLock; invalidateAll() clears the cache asynchronously under the lock, with tests covering concurrent upserts.
Await import invalidation src/core/webview/webviewMessageHandler.ts	The history import flow awaits invalidateAll() before running reconciliation and flushing the index.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested labels: awaiting-review

Suggested reviewers: hannesrudolph, navedmerchant

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: routing invalidate methods through withLock.
Description check	✅ Passed	The description includes the linked issue, implementation summary, testing steps, and checklist, with only optional sections omitted.
Linked Issues check	✅ Passed	The changes satisfy #698 by wrapping invalidate() and invalidateAll() in withLock and adding concurrency tests.
Out of Scope Changes check	✅ Passed	The only extra changes are the needed call-site await and regression tests, both directly related to the issue.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[edelauna]

Nice! Thanks for taking this on!

Two items that don't map to diff lines:

webviewMessageHandler.ts:966 — invalidateAll() is now async but is called without await. Any error it throws is silently swallowed, and a reader can't tell whether the cache clear is guaranteed to finish before the subsequent reconcile(). Consider await provider.taskHistoryStore.invalidateAll() there.

Missing lock-contention test for invalidate() — the PR wraps both invalidate() and invalidateAll() in withLock, but only invalidateAll() gets a concurrency regression test. If someone removed withLock from invalidate() in a future refactor, nothing would catch it. A parallel test modelled on the new invalidateAll() one (gate writeTaskFile, call store.invalidate(id) concurrently, assert cache reflects the written value) would close the gap.

[edelauna]

The JSDoc still says "reload from index" but the body only calls cache.clear() -- loadIndex() is never called. Worth updating to reflect the actual behavior?

[morgan-coded]

Updated the handler to await invalidateAll() and checked the remaining call sites; no other non-test callers needed the same fix. Added a deterministic invalidate() contention test that gates writeTaskFile and verifies the cache reflects the completed write, and corrected the JSDoc to note that reconcile() repopulates the cleared cache from task files. Thanks for the clear review.

[edelauna]

Thanks so much for your contribution!

[edelauna]

I did open a related issue: #949 which I noticed during review - if this is something you would like to help out with next 🙏