feat: Make checkpoint on new task

[samhvw8]

Ensures that invoking the newTaskTool always creates a checkpoint, even if no files have changed. This provides a consistent state snapshot before a sub-task is initiated.

Related GitHub Issue

Closes: #

Description

Test Procedure

Type of Change

• 🐛 Bug Fix: Non-breaking change that fixes an issue.
• ✨ New Feature: Non-breaking change that adds functionality.
• 💥 Breaking Change: Fix or feature that would cause existing functionality to not work as expected.
• ♻️ Refactor: Code change that neither fixes a bug nor adds a feature.
• 💅 Style: Changes that do not affect the meaning of the code (white-space, formatting, etc.).
• 📚 Documentation: Updates to documentation files.
• ⚙️ Build/CI: Changes to the build process or CI configuration.
• 🧹 Chore: Other changes that don't modify src or test files.

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Code Quality:
  • My code adheres to the project's style guidelines.
  • There are no new linting errors or warnings (npm run lint).
  • All debug code (e.g., console.log) has been removed.
• Testing:
  • New and/or updated tests have been added to cover my changes.
  • All tests pass locally (npm test).
  • The application builds successfully with my changes.
• Branch Hygiene: My branch is up-to-date (rebased) with the main branch.
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Changeset: A changeset has been created using npm run changeset if this PR includes user-facing changes or dependency updates.
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

Documentation Updates

Additional Notes

Get in Touch

---

Important

Ensure newTaskTool creates a checkpoint even if no files change by forcing empty commits.

• Behavior:
  • newTaskTool in newTaskTool.ts now calls checkpointSave with force=true to ensure a checkpoint is created even if no files have changed.
  • checkpointSave in index.ts updated to accept a force parameter, allowing empty commits.
• Services:
  • saveCheckpoint in ShadowCheckpointService.ts updated to handle allowEmpty option for empty commits.
• Misc:
  • Minor delay added after checkpoint creation in newTaskTool.ts.

^{This description was created by for 10535b42acd8f2fbb73b7e4b5e3c82f36de9d3e5. You can customize this summary. It will automatically update as commits are pushed.}

[daniel-lxs]

Hi again @samhvw8,
Do you think it makes sense to add a new unit test to ShadowCheckpointService.test.ts for the force empty commit behavior?

Overall I think this is a great idea, many times I wanted to revert the changes made by a subtask only to find out there was no checkpoint.

[samhvw8]

Yes, agree, i will update my code tmr 💪🏻

…

On Thu, 22 May 2025 at 23:40 Daniel ***@***.***> wrote: *daniel-lxs* left a comment (RooCodeInc/Roo-Code#3834) <#3834 (comment)> Hi again @samhvw8 <https://github.com/samhvw8>, Do you think it makes sense to add a new unit test to ShadowCheckpointService.test.ts for the force empty commit behavior? — Reply to this email directly, view it on GitHub <#3834 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC7VCZR356RBMVVUUZFQPAT27X4YVAVCNFSM6AAAAAB5WKIUCSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMBRHA4TENJUGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[hannesrudolph]

@cte Can we please merge this for now? this functionality of checkpoints with orchestrator is not useful. This would be far better than the current state of things and we don't have the time for a more complex solution at the moment.

[cte]

@cte Can we please merge this for now? this functionality of checkpoints with orchestrator is not useful. This would be far better than the current state of things and we don't have the time for a more complex solution at the moment.

Yes, I think we can merge it after it goes through code review, though as I mentioned before this isn't the way I want to solve this problem, so fair warning that there's a chance that I will revert this and re-implement it later.

[samhvw8]

@daniel-lxs Roo help me added test, can you check it

[daniel-lxs]

Hey @samhvw8, I think we should prevent the tool from failing if the checkpoint creation fails.

Also I would like to know what the delay is for.

Edit: the delay is not necessary for this to work

[daniel-lxs]

This looks good to me as a temporary solution for the checkpoint before new_task issue.