-
Notifications
You must be signed in to change notification settings - Fork 557
Fix rollback bug in tree-agent #25681
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
Conversation
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.
Pull Request Overview
This PR fixes a rollback bug in the tree-agent where successful edits following a failed edit were incorrectly rolled back. The fix ensures that only the final edit result determines whether to commit or rollback all edits in a query.
- Updated the rollback logic to only consider the last edit's success status
- Added comprehensive tests to verify the fix for both scenarios
- Improved API documentation to clarify the edit behavior
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
File | Description |
---|---|
packages/framework/tree-agent/src/agent.ts | Fixed rollback logic by replacing cumulative failure tracking with last-edit-only tracking |
packages/framework/tree-agent/src/test/agent.spec.ts | Added tests for both rollback scenarios and updated existing test name |
packages/framework/tree-agent/src/api.ts | Enhanced documentation for EditResult interface and edit method behavior |
packages/framework/tree-agent/api-report/tree-agent.alpha.api.md | Removed undocumented comment from API report |
375f149
to
5ee413d
Compare
this.options?.logger, | ||
); | ||
|
||
editFailed ||= editResult.type !== "success"; |
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.
The removal of the ||
is the key change here. Admittedly, this policy is arbitrary (rollback if and only if final edit was failure), but it seems sensible enough. Probably the most robust way to do it is to give the Model a "commit()" and "reject()" callback in addition to the edit()
callback. If they call either, we close the edit window and do as they say, otherwise we fall back to this policy. Something for a future PR, perhaps.
🔗 Found some broken links! 💔 Run a link check locally to find them. See linkcheck output
|
Currently, successful edits following a failed edit (e.g. an edit that throws a runtime error) are rolled back. Instead, if a subsequent edit succeeds, we should commit it.