Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds Atomic delegation handoff
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related issues
Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
src/core/task-persistence/__tests__/TaskHistoryStore.spec.ts (1)
445-605: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd validation coverage for updater ID changes.
Alongside the source guard, add cases where the first and second updater return a different
id, and assert no unintended task file/cache entry is written. As per coding guidelines, "**/*.{test,spec}.{ts,tsx,js}: Use package-local unit tests for pure logic, parsing, state transitions, validation, serialization, request construction, retry decisions, and error handling."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/core/task-persistence/__tests__/TaskHistoryStore.spec.ts` around lines 445 - 605, The atomicUpdatePair test coverage is missing validation for updater-generated ID changes, so add cases in TaskHistoryStore.atomicUpdatePair where the first and second updater functions return a different id. Assert that the source guard rejects or prevents the change and that no unintended task file or cache entry is created or modified for the new id. Keep the assertions aligned with the existing TaskHistoryStore.spec patterns for on-disk persistence and in-memory cache state.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/core/task-persistence/TaskHistoryStore.ts`:
- Around line 579-583: The atomicUpdatePair flow currently writes whatever IDs
the two updaters return, so validate both updated IDs before calling upsertCore.
In TaskHistoryStore.atomicUpdatePair, compare updatedFirst.id and
updatedSecond.id against the original first.id and second.id, and reject the
operation if either updater changed its task ID. Keep the existing behavior
aligned with atomicReadAndUpdate by preserving pair IDs before any writes and
only proceeding to upsertCore when both IDs still match.
In `@src/core/webview/ClineProvider.ts`:
- Around line 3771-3778: The success path in ClineProvider’s atomic history
transition updates storage via atomicUpdatePair() but never notifies the
webview, so the in-memory task history stays stale. After the paired update for
childTaskId and parentTaskId, explicitly broadcast taskHistoryItemUpdated for
both records using the same payload shape as updateTaskHistory() does, or route
this path through updateTaskHistory() so the write-through event is emitted
consistently.
---
Nitpick comments:
In `@src/core/task-persistence/__tests__/TaskHistoryStore.spec.ts`:
- Around line 445-605: The atomicUpdatePair test coverage is missing validation
for updater-generated ID changes, so add cases in
TaskHistoryStore.atomicUpdatePair where the first and second updater functions
return a different id. Assert that the source guard rejects or prevents the
change and that no unintended task file or cache entry is created or modified
for the new id. Keep the assertions aligned with the existing
TaskHistoryStore.spec patterns for on-disk persistence and in-memory cache
state.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 1dedc00c-be40-44dc-a008-c7c14f393884
📒 Files selected for processing (5)
src/__tests__/history-resume-delegation.spec.tssrc/__tests__/nested-delegation-resume.spec.tssrc/core/task-persistence/TaskHistoryStore.tssrc/core/task-persistence/__tests__/TaskHistoryStore.spec.tssrc/core/webview/ClineProvider.ts
Related GitHub Issue
Closes: #365
Description
Replaces the sentinel-based multi-step write in
reopenParentFromDelegation(parentactive→ close child → childcompleted→ clear sentinel) with a singleatomicUpdatePaircall that writeschild=completedandparent=activein one lock acquisition — no intermediate state is ever persisted.Key changes:
TaskHistoryStore.atomicUpdatePair— new public method that updates twoHistoryItems within a singlewithLockacquisition. Both updaters run before any I/O; both files are written before the lock releases. ExtractedupsertCoreprivate helper to share the write+cache logic without triggeringonWrite/index-write per record.reopenParentFromDelegationsteps 3–5 —removeClineFromStack(step 4) moved before the atomic write so any stale"active"status written byabortTaskis immediately overwritten. Steps 3, 5, and 5B collapsed into oneatomicUpdatePair(childTaskId, parentTaskId, ...)call. Falls back toupdateTaskHistoryfor the parent ifatomicUpdatePairfails.atomicUpdatePairunit tests added toTaskHistoryStore.spec.ts(happy path, concurrent upsert ordering, missing-ID throws, partial-failure/known-limitation,onWritecalled once).history-resume-delegation.spec.tsupdated to stubtaskHistoryStore.atomicUpdatePairinstead ofupdateTaskHistory; handoff-correctness and partial-failure tests added.nested-delegation-resume.spec.tsupdated withtaskHistoryStorestub.Why child first: a crash after the child write but before the parent write leaves
child=completed,parent=delegated— whichreconcileDelegationStatealready handles (resumable). A crash after the parent write but before the child write would leaveparent=activewithchild=activeand no way to report back.Test Procedure
cd src npx vitest run __tests__/history-resume-delegation.spec.ts \ __tests__/nested-delegation-resume.spec.ts \ core/task-persistence/__tests__/TaskHistoryStore.spec.tsAll 6447 tests pass (
npx vitest run).Pre-Submission Checklist
Additional Notes
assertValidTransitionreferenced in the issue pseudocode is not implemented — the guard at the top ofreopenParentFromDelegation(checkingstatus === "delegated" || status === "active"andawaitingChildId === childTaskId) already enforces valid state before the updaters run, and no transition table exists in the codebase to validate against.Summary by CodeRabbit