-
Notifications
You must be signed in to change notification settings - Fork 2.8k
feat: initial checkpoint as state-driven UI element #11085
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
Show the initial checkpoint (workspace state at task start) as a fixed UI element at the top of the chat, with visual states for pending/ready/failed. This replaces the previous approach of a header button and provides better UX: - Pending state: greyed out with spinner while initializing - Ready state: full color with restore/diff menu options - Failed state: warning styling with error indication Changes: - Add initialCheckpointState and initialCheckpointHash to extension state - New InitialCheckpoint component with three visual states - CheckpointMenu now supports isInitial prop to hide irrelevant options - Backend emits state transitions instead of messages
Re-review complete. No new issues found; two of the previously flagged issues look resolved in the latest commit.
Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues. |
| data-testid="initial-checkpoint-menu-container" | ||
| className={cn("h-4 -mt-2", menuVisible ? "block" : "hidden")}> | ||
| <CheckpointMenu | ||
| ts={0} // Initial checkpoint doesn't have a ts |
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.
In InitialCheckpoint, CheckpointMenu is passed ts={0}, but the backend restore handler looks up the target message by timestamp and returns early if it cannot find a matching message. Since no chat message will ever have ts=0, initial checkpoint preview/restore will be a no-op. Consider making restore preview independent of ts, special-casing initial restore to rewind to task start, or passing a real ts for the restore point.
Fix it with Roo Code or mention @roomote and request a fix.
| </div> | ||
| <span | ||
| className={cn("block w-full h-[2px] mt-[2px] text-xs")} | ||
| style={{ | ||
| backgroundImage: isPending | ||
| ? "linear-gradient(90deg, rgba(128, 128, 128, .4), rgba(128, 128, 128, .4) 80%, rgba(128, 128, 128, 0) 99%)" | ||
| : isFailed | ||
| ? "linear-gradient(90deg, rgba(239, 68, 68, .4), rgba(239, 68, 68, .4) 80%, rgba(239, 68, 68, 0) 99%)" | ||
| : "linear-gradient(90deg, rgba(0, 188, 255, .65), rgba(0, 188, 255, .65) 80%, rgba(0, 188, 255, 0) 99%)", | ||
| }}></span> |
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.
InitialCheckpoint uses an inline style for the gradient. This project prefers Tailwind + VSCode CSS vars for new markup; inline styles here will be harder to theme and keep consistent. Consider extracting the gradient into a class (or using existing utility patterns) so theme changes can be handled in CSS.
Fix it with Roo Code or mention @roomote and request a fix.
The initial checkpoint has no message in clineMessages (ts=0 doesn't exist), so checkpointRestore was returning early without doing anything. Now when isInitial=true is passed in the restore payload, the handler calls checkpointRestoreToBase() instead which properly restores to the baseHash without needing to find a message.
| // For initial checkpoint, use checkpointRestoreToBase instead of checkpointRestore | ||
| // because there's no message with ts to find in clineMessages | ||
| if (result.data.isInitial) { | ||
| const { checkpointRestoreToBase } = await import("../checkpoints") |
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.
In the initial-checkpoint path, this uses a dynamic import from "../checkpoints", but the only checkpoints module here appears to be src/core/checkpoints/index.ts (and it does not export checkpointRestoreToBase). As written, the restore action will throw at runtime (module or export not found) and the initial restore will fail.
Fix it with Roo Code or mention @roomote and request a fix.
This function was in the old PR #10908 but was not included when we created the new branch from origin/main. It's needed for restoring to the initial checkpoint state.
Re-review complete. One remaining issue flagged.
Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues. |
| </div> | ||
| <span | ||
| className={cn("block w-full h-[2px] mt-[2px] text-xs")} | ||
| style={{ |
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.
InitialCheckpoint uses an inline style to set the gradient background. This makes the element harder to theme (VS Code theme vars) and goes against the project preference for Tailwind/CSS vars for new markup; consider moving these gradients into CSS (eg a small class per state) and toggling via className instead.
Fix it with Roo Code or mention @roomote and request a fix.
Summary
Show the initial checkpoint (workspace state at task start) as a fixed UI element at the top of the chat, with visual states for pending/ready/failed.
This replaces the previous approach from PR #10908 (now closed) and provides better UX:
Changes
Backend (
src/core/checkpoints/index.ts)sendInitialCheckpointState()helper functionpending→readyorfailed) instead of messagesTypes (
packages/types/src/vscode-extension-host.ts)initialCheckpointState: 'pending' | 'ready' | 'failed' | nullto ExtensionMessage/ExtensionStateinitialCheckpointHash: string | nullfor the commit hash when readyWebview
InitialCheckpointcomponent with three visual statesCheckpointMenunow supportsisInitialprop to hide irrelevant options ("View Diff" vs previous, "View All Changes")ExtensionStateContextChatViewbelow TaskHeaderTests
InitialCheckpointcomponentWhy this approach?
The checkpoint initialization is async and can take time. Instead of showing the checkpoint in the wrong position (middle of chat) when it finishes, we:
Screenshots
[Screenshots would go here showing pending/ready/failed states]
Related
Important
Introduces
InitialCheckpointUI component to display initial checkpoint state with distinct visual feedback for pending, ready, and failed states in a chat application.InitialCheckpointcomponent to display initial checkpoint state inChatView.pending,ready, andfailedstates with distinct UI feedback.ExtensionStateContextto manage state.sendInitialCheckpointState()inindex.tsto emit state transitions.ExtensionMessageandExtensionStateinvscode-extension-host.tsto includeinitialCheckpointStateandinitialCheckpointHash.ChatView.tsxto renderInitialCheckpointbelowTaskHeader.CheckpointMenuto supportisInitialprop.InitialCheckpointandCheckpointSavedcomponents.This description was created by
for 7ee88cc. You can customize this summary. It will automatically update as commits are pushed.