Conversation
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughThe PR implements automatic worktree selection when features are created with new branches. It refactors the worktree panel UI to split main and non-main worktrees, adds periodic background refresh, and enhances test reliability with improved synchronization and polling logic. Changes
Sequence Diagram(s)sequenceDiagram
participant UI as UI (Board View)
participant Hook as useBoardActions
participant Store as Store
participant Panel as Worktree Panel
UI->>Hook: handleAddFeature(newBranch)
Hook->>Store: Create feature with new branch
Hook->>Hook: Create new worktree entry
activate Hook
Hook->>Panel: onWorktreeAutoSelect({ path, branch })
deactivate Hook
Panel->>Panel: Verify no duplicate worktree exists
Panel->>Store: Append new worktree to store
Panel->>Store: Select worktree (set current path/branch)
Panel->>UI: Update UI with selected worktree
UI->>UI: Auto-select worktree in panel
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
Summary of ChangesHello @webdevcody, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request streamlines the workflow for creating new features by automatically selecting the corresponding Git worktree upon its creation. This enhancement improves user experience by immediately switching the development context. Additionally, it includes a critical fix to prevent race conditions in worktree state validation, ensuring more robust and reliable worktree management within the application. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a helpful feature to auto-select a worktree when a new feature is created for it. It also includes a good fix for a race condition in the worktree validation logic. My review focuses on improving the code structure by moving state logic out of the view component and enhancing the quality and reliability of the new integration test.
| await confirmAddFeature(page); | ||
|
|
||
| // Wait for feature to be saved and worktree to be created | ||
| await page.waitForTimeout(2000); |
There was a problem hiding this comment.
The use of page.waitForTimeout(2000) can lead to flaky tests. It's a fixed wait that might be too short on a slow machine or too long on a fast one, slowing down the test suite. It's better to rely on Playwright's auto-waiting capabilities by waiting for a specific condition to be met. In this case, you can directly wait for the worktree button to become visible and then for it to have the 'active' state.
I suggest removing this line. The subsequent expect(worktreeButton).toBeVisible(...) and expect(worktreeButton).toHaveAttribute(...) calls with their timeouts are sufficient and more reliable.
| onWorktreeAutoSelect: (newWorktree) => { | ||
| if (!currentProject) return; | ||
| // Check if worktree already exists in the store (by branch name) | ||
| const currentWorktrees = getWorktrees(currentProject.path); | ||
| const existingWorktree = currentWorktrees.find( | ||
| (w) => w.branch === newWorktree.branch | ||
| ); | ||
|
|
||
| // Only add if it doesn't already exist (to avoid duplicates) | ||
| if (!existingWorktree) { | ||
| const newWorktreeInfo = { | ||
| path: newWorktree.path, | ||
| branch: newWorktree.branch, | ||
| isMain: false, | ||
| isCurrent: false, | ||
| hasWorktree: true, | ||
| }; | ||
| setWorktrees(currentProject.path, [ | ||
| ...currentWorktrees, | ||
| newWorktreeInfo, | ||
| ]); | ||
| } | ||
| // Select the worktree (whether it existed or was just added) | ||
| setCurrentWorktree( | ||
| currentProject.path, | ||
| newWorktree.path, | ||
| newWorktree.branch | ||
| ); | ||
| }, |
There was a problem hiding this comment.
The logic for onWorktreeAutoSelect is implemented directly within the BoardView component. This business logic, which involves reading from and writing to the application state, would be better placed within the useAppStore Zustand store as a dedicated action. This would improve separation of concerns, make the BoardView component cleaner, and centralize state management logic.
I suggest creating a new action in app-store.ts, for example autoSelectWorktree, and calling it from use-board-actions.ts. This would also remove the need to pass onWorktreeAutoSelect as a prop.
| // Verify the feature is visible in the backlog (which means the worktree is selected) | ||
| const featureText = page.getByText("Feature with auto-select worktree"); | ||
| await expect(featureText).toBeVisible({ timeout: 5000 }); |
There was a problem hiding this comment.
This verification block is redundant. The same check (expect(featureText).toBeVisible(...)) is already performed within the .catch() block of the preceding assertion on lines 885-890. If the primary assertion on the button's data-state fails, the fallback in the catch block runs. In either case, this final check is duplicative. To keep the test DRY and focused, this block should be removed.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
apps/app/src/components/views/board-view/hooks/use-board-actions.ts (1)
119-141: Consider handling the case when result.success is true but result.worktree is missing.The current logic has three possible outcomes:
result.success && result.worktree→ auto-select and refresh (lines 120-131)!result.success→ show error (lines 132-140)result.success && !result.worktree→ no handling (falls through silently)Case 3 seems unexpected. If the API returns success but no worktree object, should this be logged or treated as an error? Consider adding an else clause to handle or at least log this edge case.
🔎 Proposed fix to handle all cases
if (result.success && result.worktree) { console.log( `[Board] Worktree for branch "${finalBranchName}" ${ result.worktree?.isNew ? "created" : "already exists" }` ); // Auto-select the worktree when creating a feature for it onWorktreeAutoSelect?.({ path: result.worktree.path, branch: result.worktree.branch, }); // Refresh worktree list in UI onWorktreeCreated?.(); } else if (!result.success) { console.error( `[Board] Failed to create worktree for branch "${finalBranchName}":`, result.error ); toast.error("Failed to create worktree", { description: result.error || "An error occurred", }); + } else { + // result.success is true but result.worktree is missing - unexpected + console.warn( + `[Board] Worktree creation succeeded but no worktree object returned for branch "${finalBranchName}"` + ); }
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
apps/app/src/components/views/board-view.tsx(1 hunks)apps/app/src/components/views/board-view/hooks/use-board-actions.ts(4 hunks)apps/app/src/components/views/board-view/worktree-panel/hooks/use-worktrees.ts(2 hunks)apps/app/tests/worktree-integration.spec.ts(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (2)
apps/app/src/components/views/board-view/worktree-panel/hooks/use-worktrees.ts (1)
apps/app/src/lib/utils.ts (1)
pathsEqual(51-54)
apps/app/tests/worktree-integration.spec.ts (4)
apps/app/tests/utils/git/worktree.ts (3)
setupProjectWithPath(309-353)waitForBoardView(462-464)listBranches(194-200)apps/app/tests/utils/core/waiting.ts (1)
waitForNetworkIdle(7-9)apps/app/tests/utils/api/client.ts (1)
listBranches(179-189)apps/app/tests/utils/views/board.ts (3)
clickAddFeature(121-126)fillAddFeatureDialog(131-180)confirmAddFeature(185-192)
🔇 Additional comments (5)
apps/app/src/components/views/board-view/worktree-panel/hooks/use-worktrees.ts (2)
3-3: LGTM! Clean ref pattern to avoid race condition.The useRef pattern correctly captures the current worktree value, allowing the validation effect to access the latest selection without depending on it directly in the dependency array. This prevents the validation effect from running on every selection change, which could cause a race condition with stale worktrees data.
Also applies to: 62-67
69-88: Well-designed fix for the race condition.The validation effect now only triggers when the worktrees list changes, not when the selection changes. By using the ref to access the current selection, this prevents a race condition where a selection change could trigger validation before the worktrees list is updated, causing an incorrect reset to main.
The logic correctly:
- Checks if the current selection still exists in the updated worktrees list
- Resets to main branch only if the current worktree is invalid or no longer exists
- Excludes
currentWorktreefrom dependencies to avoid the race conditionapps/app/src/components/views/board-view.tsx (1)
416-444: LGTM! Auto-selection logic is correctly implemented.The callback properly:
- Checks for existing worktrees by branch to avoid duplicates
- Adds the new worktree to the store with correct structure
- Selects the worktree regardless of whether it was just added or already existed
The
newWorktreeInfostructure correctly setsisMain: false,isCurrent: false, andhasWorktree: truefor the newly created/found worktree.apps/app/src/components/views/board-view/hooks/use-board-actions.ts (2)
44-44: LGTM! Clean type definition.The optional
onWorktreeAutoSelectprop is properly typed with the correct structure ({ path: string; branch: string }), and it's correctly destructured in the function signature.Also applies to: 72-72
161-161: LGTM! Dependency array is complete.The dependency array correctly includes
onWorktreeAutoSelectalong with all other dependencies used in the callback.
- Simplified the formatting of dropdown open change handlers for better readability. - Updated the label from "Branch:" to "Worktrees:" for clarity. - Enhanced conditional checks for removed worktrees to improve code structure.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
apps/ui/src/components/views/board-view.tsx (1)
421-449: Duplicated worktree creation logic — consider extracting to a shared helper or store action.This
onWorktreeAutoSelectcallback duplicates the logic inCreateWorktreeDialog.onCreated(lines 1161-1186). Both:
- Check for existing worktrees by branch
- Create a
newWorktreeInfoobject with the same shape- Append to worktrees via
setWorktrees- Call
setCurrentWorktreeAs noted in a previous review, consolidating this into a dedicated Zustand store action (e.g.,
addAndSelectWorktree) would eliminate duplication, centralize state management, and simplify the component.
🧹 Nitpick comments (2)
apps/ui/src/components/views/board-view/worktree-panel/components/worktree-tab.tsx (1)
154-189: Consider using a native<button>element instead of<span role="button">.While the current implementation with
role="button",tabIndex={0}, and keyboard handling is functionally correct, a native<button>element provides these accessibility features by default and handles additional edge cases (e.g., form submission context, disabled state behavior). The styling can still be customized with utility classes.If there's a specific reason for avoiding a nested button (e.g., HTML validation concerns with button-inside-button), you could extract the badge outside the parent button's DOM hierarchy or use CSS pointer-events to manage the interaction.
apps/ui/src/components/views/board-view/hooks/use-board-actions.ts (1)
185-218: Note:handleUpdateFeaturedoesn't auto-select newly created worktrees.Unlike
handleAddFeature, this function creates a worktree for the branch but doesn't callonWorktreeAutoSelect. This asymmetry appears intentional (editing shouldn't change the user's current view), but worth confirming this is the desired UX.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
apps/app/next-env.d.ts(1 hunks)apps/ui/src/components/views/board-view.tsx(1 hunks)apps/ui/src/components/views/board-view/hooks/use-board-actions.ts(4 hunks)apps/ui/src/components/views/board-view/worktree-panel/components/worktree-tab.tsx(2 hunks)apps/ui/src/components/views/board-view/worktree-panel/hooks/use-worktrees.ts(2 hunks)apps/ui/src/components/views/board-view/worktree-panel/worktree-panel.tsx(4 hunks)
✅ Files skipped from review due to trivial changes (1)
- apps/app/next-env.d.ts
🧰 Additional context used
🧬 Code graph analysis (1)
apps/ui/src/components/views/board-view/worktree-panel/worktree-panel.tsx (3)
apps/ui/src/components/views/board-view/worktree-panel/types.ts (1)
WorktreeInfo(9-18)apps/ui/src/types/electron.d.ts (1)
WorktreeInfo(578-583)apps/ui/src/lib/electron.ts (1)
WorktreeInfo(52-52)
🔇 Additional comments (3)
apps/ui/src/components/views/board-view/worktree-panel/worktree-panel.tsx (1)
90-103: LGTM!The formatting improvements and label update from "Branch:" to "Worktrees:" are clean cosmetic changes with no functional impact.
Also applies to: 112-112, 141-146, 180-184
apps/ui/src/components/views/board-view/worktree-panel/hooks/use-worktrees.ts (1)
61-87: Good use of ref to decouple validation from selection changes.The
currentWorktreeRefpattern correctly prevents the validation effect from re-running when the user selects a worktree, avoiding the race condition where staleworktreesstate could incorrectly reset the selection.One subtle note: when
worktreesupdates, the validation effect reads the previouscurrentWorktreevalue from the ref (since the ref-sync effect runs oncurrentWorktreechanges, notworktreeschanges). This appears intentional and correct for this use case — you validate against the previously established selection, not a concurrent selection change.apps/ui/src/components/views/board-view/hooks/use-board-actions.ts (1)
119-132: LGTM — auto-select correctly integrated for new features.The null check on
result.worktreebefore accessing its properties is correct. The optional chaining ononWorktreeAutoSelect?.()safely handles cases where the callback isn't provided.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
apps/ui/src/components/views/board-view.tsx (1)
421-449: Acknowledge the existing review feedback regarding state management location.A previous review suggested moving this
onWorktreeAutoSelectlogic into the Zustand store as a dedicated action rather than implementing it directly in the component. This would improve separation of concerns and centralize state management.The current implementation is functional, but consider refactoring this into
app-store.tsas anautoSelectWorktreeaction in a future iteration.Based on past review comments suggesting this logic belongs in the Zustand store rather than the component.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
apps/ui/src/components/views/board-view.tsx(1 hunks)apps/ui/src/components/views/board-view/hooks/use-board-actions.ts(7 hunks)apps/ui/src/components/views/board-view/worktree-panel/components/worktree-tab.tsx(2 hunks)apps/ui/src/components/views/board-view/worktree-panel/hooks/use-worktrees.ts(4 hunks)apps/ui/src/components/views/board-view/worktree-panel/worktree-panel.tsx(5 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/ui/src/components/views/board-view/worktree-panel/components/worktree-tab.tsx
🧰 Additional context used
🧬 Code graph analysis (1)
apps/ui/src/components/views/board-view/worktree-panel/worktree-panel.tsx (2)
apps/ui/src/components/views/board-view/worktree-panel/types.ts (1)
WorktreeInfo(9-18)apps/ui/src/components/views/board-view/worktree-panel/components/worktree-tab.tsx (1)
WorktreeTab(55-337)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: e2e
🔇 Additional comments (5)
apps/ui/src/components/views/board-view/worktree-panel/hooks/use-worktrees.ts (2)
66-92: Well-designed solution to prevent race conditions.The ref-based approach (
currentWorktreeRef) effectively prevents the validation effect from racing with selection changes. By only running validation when the worktrees list changes (not on selection changes), you avoid the issue where stale worktree data causes the selection to be reset prematurely.This is a clean pattern for handling async state synchronization issues.
23-50: Silent fetch option improves UX for background refreshes.The optional
silentflag allows periodic background refreshes without showing loading indicators, which is appropriate for the 1-second polling interval introduced inworktree-panel.tsx. This prevents unnecessary UI flickering.apps/ui/src/components/views/board-view/hooks/use-board-actions.ts (2)
120-133: Auto-select flow correctly implemented.The
onWorktreeAutoSelectcallback is invoked at the right point in the flow—after successful worktree creation and before the UI refresh. This ensures the newly created worktree is automatically selected, providing a seamless user experience.The conditional logic properly checks for both
result.successandresult.worktreebefore invoking the callback.
199-209: Dependency array correctly updated.The
onWorktreeAutoSelectcallback has been properly included in thehandleAddFeaturedependency array, ensuring the memoized function stays current when the callback reference changes.apps/ui/src/components/views/board-view/worktree-panel/worktree-panel.tsx (1)
154-340: Well-structured UI refactoring for main and non-main worktrees.The separation of main worktree and non-main worktrees into distinct sections improves clarity and user experience. The main worktree is always visible under "Branch:", while additional worktrees appear under "Worktrees:" when enabled.
The refactored dropdown handlers using currying are clean and maintainable.
| // Periodic interval check (1 second) to detect branch changes on disk | ||
| const intervalRef = useRef<NodeJS.Timeout | null>(null); | ||
| useEffect(() => { | ||
| intervalRef.current = setInterval(() => { | ||
| fetchWorktrees({ silent: true }); | ||
| }, 1000); | ||
|
|
||
| return () => { | ||
| if (intervalRef.current) { | ||
| clearInterval(intervalRef.current); | ||
| } | ||
| }; | ||
| }, [fetchWorktrees]); |
There was a problem hiding this comment.
Consider increasing the polling interval to reduce overhead.
A 1-second polling interval may be too aggressive, especially when the panel is expanded and users are actively working. This creates 60 API calls per minute to check for branch changes on disk.
Consider:
- Increasing the interval to 5-10 seconds for a better balance between responsiveness and resource usage
- Implementing a smart polling strategy that polls more frequently when changes are detected
- Using file system watchers (if available in Electron) instead of polling
🔎 Suggested interval adjustment
useEffect(() => {
intervalRef.current = setInterval(() => {
fetchWorktrees({ silent: true });
- }, 1000);
+ }, 5000); // Poll every 5 seconds instead of 1 second📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // Periodic interval check (1 second) to detect branch changes on disk | |
| const intervalRef = useRef<NodeJS.Timeout | null>(null); | |
| useEffect(() => { | |
| intervalRef.current = setInterval(() => { | |
| fetchWorktrees({ silent: true }); | |
| }, 1000); | |
| return () => { | |
| if (intervalRef.current) { | |
| clearInterval(intervalRef.current); | |
| } | |
| }; | |
| }, [fetchWorktrees]); | |
| // Periodic interval check (1 second) to detect branch changes on disk | |
| const intervalRef = useRef<NodeJS.Timeout | null>(null); | |
| useEffect(() => { | |
| intervalRef.current = setInterval(() => { | |
| fetchWorktrees({ silent: true }); | |
| }, 5000); // Poll every 5 seconds instead of 1 second | |
| return () => { | |
| if (intervalRef.current) { | |
| clearInterval(intervalRef.current); | |
| } | |
| }; | |
| }, [fetchWorktrees]); |
- Updated spec editor persistence test to wait for loading state and content updates. - Improved worktree integration test to ensure worktree button visibility and selected state after creation. - Refactored getEditorContent function to ensure CodeMirror content is fully loaded before retrieval.
- Increased wait times in spec editor persistence test to ensure content is fully loaded and saved. - Added verification of content before saving in the spec editor test. - Marked worktree panel visibility test as skipped due to flakiness caused by component rendering behavior.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
apps/ui/tests/spec-editor-persistence.spec.ts (2)
66-70: Consider removing redundant wait after save.The
clickSaveButtonutility already waits up to 5 seconds for the button text to change to "Saved", indicating the save operation is complete. The additional 1000ms wait at line 70 is likely redundant and slows down the test unnecessarily.🔎 Suggested simplification
// Step 8: Click the save button and wait for save to complete await clickSaveButton(page); - -// Additional wait to ensure save operation completes and file is written -await page.waitForTimeout(1000);
96-111: Consider removing redundant wait before content polling.The content polling logic (lines 99-111) already waits up to 15 seconds for the content to match, checking continuously. The fixed 1000ms wait at line 97 is likely redundant—if CodeMirror needs time to update, the polling will handle it.
🔎 Suggested simplification
); - -// Additional wait for CodeMirror to update after loading -await page.waitForTimeout(1000); // Wait for CodeMirror content to update with the loaded spec -// CodeMirror might need a moment to update its DOM after the value prop changes await page.waitForFunction(
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/ui/tests/spec-editor-persistence.spec.ts(2 hunks)apps/ui/tests/worktree-integration.spec.ts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/ui/tests/worktree-integration.spec.ts
🧰 Additional context used
🧬 Code graph analysis (1)
apps/ui/tests/spec-editor-persistence.spec.ts (1)
apps/ui/tests/utils/views/spec-editor.ts (3)
setEditorContent(79-105)getEditorContent(65-74)clickSaveButton(110-122)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: e2e
🔇 Additional comments (3)
apps/ui/tests/spec-editor-persistence.spec.ts (3)
57-57: Increased wait addresses editor initialization timing.The increased timeout from 500ms to 1000ms may help with CodeMirror initialization, though fixed timeouts are generally less reliable than explicit state checks. If this addresses real flakiness, it's acceptable.
62-64: Good addition: pre-save content verification.Verifying the editor content before saving ensures
setEditorContentsucceeded and makes the test more robust by catching issues earlier in the flow.
87-94: Good addition: explicit loading state check.Waiting for the loading indicator to disappear is a robust approach that ensures the spec has finished loading before proceeding.
- Removed unnecessary wait times to streamline the test flow. - Implemented a polling mechanism to verify content loading after page reload, enhancing test robustness. - Updated the worktree integration test to skip unreliable scenarios related to component rendering.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/ui/tests/spec-editor-persistence.spec.ts (1)
81-117: Simplify using Playwright's built-in retry mechanisms.The custom polling loop with
waitForTimeoutadds complexity and uses a Playwright anti-pattern. The fallback logic suggests the polling approach may not be fully reliable. Consider these simpler, more idiomatic alternatives:Option 1 (recommended): Use Playwright's expect with built-in retry
// Wait for CodeMirror content to update with the loaded spec await expect(page.locator('[data-testid="spec-editor"] .cm-content')) .toHaveText("hello world", { timeout: 30000 });Option 2: Use only the waitForFunction approach
// Wait for CodeMirror content to update with the loaded spec await page.waitForFunction( (expectedContent) => { const contentElement = document.querySelector('[data-testid="spec-editor"] .cm-content'); if (!contentElement) return false; const text = (contentElement.textContent || "").trim(); return text === expectedContent; }, "hello world", { timeout: 30000 } );Both alternatives eliminate the manual polling loop and
waitForTimeout, which is discouraged in Playwright documentation.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/ui/tests/spec-editor-persistence.spec.ts(2 hunks)apps/ui/tests/worktree-integration.spec.ts(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/ui/tests/worktree-integration.spec.ts
🧰 Additional context used
🧬 Code graph analysis (1)
apps/ui/tests/spec-editor-persistence.spec.ts (1)
apps/ui/tests/utils/views/spec-editor.ts (1)
getEditorContent(65-74)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: e2e
🔇 Additional comments (1)
apps/ui/tests/spec-editor-persistence.spec.ts (1)
59-61: Good addition: Pre-save content verification.This verification step ensures the editor content was successfully set before attempting to save, which improves test reliability and makes failures easier to diagnose.
1 participant
Changes from branch worktree-select
Summary by CodeRabbit
New Features
Tests
✏️ Tip: You can customize this high-level summary in your review settings.