-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Auto-delete task history on plugin load (retention + checkpoint cleanup) #9262
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Re-reviewed latest commit(s) on this PR (2ade8a0). No new issues found.
Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues. |
784a70d to
67c7629
Compare
d9b68d5 to
42d73fe
Compare
84853c9 to
cc67f71
Compare
heyseth
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Executive Summary
This PR introduces an auto-delete task history feature that purges old tasks on extension reload. The implementation is well-architected, type-safe, and thoroughly tested. The code demonstrates solid engineering practices with proper error handling, i18n support, and integration with existing deletion logic.
Strengths
- ✅Consistency: Excellent reuse of existing
deleteTaskWithId()logic ensures checkpoints, shadow repos, and state are cleaned up alongside files. - ✅Reliability: Sequential deletion prevents race conditions, and robust retry logic handles stubborn filesystem operations.
- ✅Quality: Full i18n support across 17 languages and type-safe schema validation with Zod.
Suggested Enhancements (Code Included)
I have included specific code snippets in the comments to address performance and user trust:
1. Performance: Non-blocking Activation (Critical)
The current implementation awaits the purge process during the activate phase. On machines with large histories or slow disks, this will block the extension startup.
- Fix: I provided a snippet to wrap the logic in a background "fire-and-forget" task (
void (async ...)), ensuring the extension activates immediately. - Optimization: Added an early return check for
retention === "never"to skip the logic entirely for the majority of users.
2. UX: Visibility & Trust
Silent deletion of user data can be alarming if a user expects to find a task.
- Fix: I added a Toast Notification logic to the background task. It only triggers if files were actually deleted and provides a direct link to Settings.
3. Testing: Edge Case Coverage
Since we are permanently deleting files, I identified a gap in testing regarding "Orphan Checkpoints" and "Legacy Mtime Fallback."
- Fix: I drafted 4 specific test cases to verify we strictly target garbage data and do not accidentally delete recent, valid tasks that lack metadata.
Conclusion
This is a high-value maintenance feature. Once the activation blocking issue is resolved (using the background task pattern I suggested), this logic is solid and ready for production!
cc67f71 to
ab6d3ab
Compare
Co-authored-by: Seth Miller <sethmillerp@gmail.com>
Co-authored-by: Seth Miller <sethmillerp@gmail.com>
…plugin reload - Updated description and warning text for aboutRetention in all 18 languages - Changed 'plugin reload' to 'extension is activated' for clarity - Changed 'deletes tasks' to 'deletes old tasks' to clarify it doesn't delete all tasks
- Add storage usage display showing total size and task count - Add calculateTaskStorageSize utility to compute global storage folder sizes - Add getTaskStorageSize message handler to communicate storage info to webview - Update About settings section to display storage usage with refresh button - Add taskHistoryStorage translations for all 18 supported languages
- Add non-blocking background task history purge on extension activation - Fire-and-forget pattern prevents blocking startup - Skip purge entirely when retention is 'never' (default) - Remove duplicate 'settings.taskHistoryRetention.description' keys from all 18 package.nls.*.json files - Keep consistent 'extension reload' terminology (vs 'plugin reload')
…cleaner code - Resolved merge conflict in extension.ts, keeping extracted function approach - startBackgroundRetentionPurge() encapsulates all purge logic in task-history-retention.ts - Added getStorageBasePath mock to task-storage-size tests (addresses roomote review)
- Check if workspace repo directory exists before git operations in deleteTask() - Reduce log verbosity - only log actual errors, not expected cases - Add test case for non-existent directory handling
69efab6 to
ee34d6a
Compare
Co-authored-by: roomote[bot] <219738659+roomote[bot]@users.noreply.github.com>
| const normalizedTaskHistoryRetention: TaskHistoryRetentionSetting = TASK_HISTORY_RETENTION_OPTIONS.includes( | ||
| taskHistoryRetention as TaskHistoryRetentionSetting, | ||
| ) | ||
| ? (taskHistoryRetention as TaskHistoryRetentionSetting) | ||
| : "never" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing here - can this logic go inside the AboutTab (or whichever tab is best for this to live in)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ehhh I guess if we have the logic for all of the other tabs in SettingsView this is following the pattern, not blocking feedback
| "warning": "Warning: This action permanently deletes old tasks and runs when the extension is activated.", | ||
| "options": { | ||
| "never": "Never", | ||
| "90": "90 days", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code might be cleaner if we pass in the number of days and don't need so many strings, but not a blocker
|
|
||
| vscode.window.showInformationMessage(message, viewSettingsLabel, dismissLabel).then((action) => { | ||
| if (action === viewSettingsLabel) { | ||
| // Navigate to Roo Code settings About tab |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this actually go to the About tab? I think we do have a way to open settings pointed to a specific tab fwiw
Closes #10850
Summary
Adds an auto-delete task history feature that purges old tasks on extension reload, helping users manage disk space and keep their task history clean.
Changes
New Setting
roo-cline.taskHistoryRetentionPurge Logic (
src/utils/task-history-retention.ts)task_metadata.jsontimestampcheckpoints/subdirectory)ClineProvider.deleteTaskWithId()to ensure consistent cleanup of checkpoints, shadow repositories, and task stateUI Updates
About.tsxsettings panelTesting
task-history-retention.spec.tscovering:Technical Notes
Important
Introduces auto-delete task history feature with configurable retention periods, UI updates, and comprehensive testing.
task-history-retention.tsdeletes tasks older than retention period, handles orphan checkpoint-only folders, and retries stubborn filesystem operations.About.tsxin settings panel.task-history-retention.spec.tsfor retention periods, dry run mode, and invalid metadata handling.global-settings.tsandvscode-extension-host.tsfor new settings.task-storage-size.tsfor calculating task storage size.This description was created by
for 2ade8a0. You can customize this summary. It will automatically update as commits are pushed.