-
Notifications
You must be signed in to change notification settings - Fork 198
multi-repo #210
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
multi-repo #210
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| if (response.ok) { | ||
| const repos: GitHubRepo[] = await response.json() | ||
| return repos.map((repo) => ({ ...repo, owner: owner.login })) | ||
| } |
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.
| if (response.ok) { | |
| const repos: GitHubRepo[] = await response.json() | |
| return repos.map((repo) => ({ ...repo, owner: owner.login })) | |
| } | |
| if (!response.ok) { | |
| console.error(`Failed to load repos for owner ${owner.login}: HTTP ${response.status}`) | |
| return [] | |
| } | |
| const repos: GitHubRepo[] = await response.json() | |
| return repos.map((repo) => ({ ...repo, owner: owner.login })) |
HTTP error responses when fetching repos are silently ignored with no error logging or user notification, resulting in incomplete repo lists without user awareness.
View Details
Analysis
Missing error logging for failed repo fetches in MultiRepoDialog
What fails: MultiRepoDialog silently ignores HTTP error responses when fetching repositories for multiple owners. When /api/github/repos?owner=X returns a non-ok status (401, 403, 500, etc.), no error is logged to console and the user receives no notification, resulting in incomplete repository lists without any indication of failure.
How to reproduce:
- Open MultiRepoDialog with multiple GitHub owners configured
- Configure API endpoint to return 403 Forbidden for at least one owner's repos
- Open the dialog and trigger the repo loading effect
Result: When an owner's repo fetch fails with HTTP error status:
- Dialog shows fewer repos than expected (gaps in list)
- No console error is logged (unlike network exceptions which are logged)
- User sees no indication that some repos failed to load
- Inconsistent with other similar components (repo-selector.tsx, repo-commits.tsx, file-editor.tsx)
Expected: Non-ok HTTP responses should be logged to console with owner and status code for debugging, matching the pattern established elsewhere in the codebase.
Fix: Added error logging when response.ok is false, logging the owner name and HTTP status code to help developers identify which owners' repos failed to load.
| // Check if this is multi-repo mode | ||
| if (multiRepoMode && selectedRepos.length > 0) { | ||
| // Create multiple tasks, one for each selected repo | ||
| const taskIds: string[] = [] | ||
| const tasksData = selectedRepos.map((repo) => { | ||
| const { id } = addTaskOptimistically({ | ||
| prompt: data.prompt, | ||
| repoUrl: repo.clone_url, | ||
| selectedAgent: data.selectedAgent, | ||
| selectedModel: data.selectedModel, | ||
| installDependencies: data.installDependencies, | ||
| maxDuration: data.maxDuration, | ||
| }) | ||
| taskIds.push(id) | ||
| return { | ||
| id, | ||
| prompt: data.prompt, | ||
| repoUrl: repo.clone_url, | ||
| selectedAgent: data.selectedAgent, | ||
| selectedModel: data.selectedModel, | ||
| installDependencies: data.installDependencies, | ||
| maxDuration: data.maxDuration, | ||
| keepAlive: data.keepAlive, | ||
| } | ||
| }) | ||
|
|
||
| // Navigate to the first task | ||
| router.push(`/tasks/${taskIds[0]}`) | ||
|
|
||
| try { | ||
| // Create all tasks in parallel | ||
| const responses = await Promise.all( | ||
| tasksData.map((taskData) => | ||
| fetch('/api/tasks', { | ||
| method: 'POST', | ||
| headers: { | ||
| 'Content-Type': 'application/json', | ||
| }, | ||
| body: JSON.stringify(taskData), | ||
| }), | ||
| ), | ||
| ) | ||
|
|
||
| const successCount = responses.filter((r) => r.ok).length | ||
| const failCount = responses.length - successCount | ||
|
|
||
| if (successCount === responses.length) { | ||
| toast.success(`${successCount} tasks created successfully!`) | ||
| } else if (successCount > 0) { | ||
| toast.warning(`${successCount} tasks created, ${failCount} failed`) | ||
| } else { | ||
| toast.error('Failed to create tasks') | ||
| } | ||
|
|
||
| // Clear selected repos after creating tasks | ||
| setSelectedRepos([]) | ||
|
|
||
| // Refresh sidebar to get the real task data from server | ||
| await refreshTasks() | ||
| } catch (error) { | ||
| console.error('Error creating tasks:', error) | ||
| toast.error('Failed to create tasks') | ||
| await refreshTasks() | ||
| } finally { | ||
| setIsSubmitting(false) | ||
| } | ||
| return |
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.
Multi-repo mode is not exited after task submission, leaving the UI showing "Multi-repo" with "0 repos selected" in an inconsistent state.
View Details
📝 Patch Details
diff --git a/components/home-page-content.tsx b/components/home-page-content.tsx
index 72843b2..f3e7e41 100644
--- a/components/home-page-content.tsx
+++ b/components/home-page-content.tsx
@@ -13,7 +13,7 @@ import { Button } from '@/components/ui/button'
import { redirectToSignIn } from '@/lib/session/redirect-to-sign-in'
import { GitHubIcon } from '@/components/icons/github-icon'
import { getEnabledAuthProviders } from '@/lib/auth/providers'
-import { useSetAtom, useAtom, useAtomValue } from 'jotai'
+import { useSetAtom, useAtom } from 'jotai'
import { taskPromptAtom } from '@/lib/atoms/task'
import { HomePageMobileFooter } from '@/components/home-page-mobile-footer'
import { multiRepoModeAtom, selectedReposAtom } from '@/lib/atoms/multi-repo'
@@ -51,7 +51,7 @@ export function HomePageContent({
const setTaskPrompt = useSetAtom(taskPromptAtom)
// Multi-repo mode state
- const multiRepoMode = useAtomValue(multiRepoModeAtom)
+ const [multiRepoMode, setMultiRepoMode] = useAtom(multiRepoModeAtom)
const [selectedRepos, setSelectedRepos] = useAtom(selectedReposAtom)
// Check which auth providers are enabled
@@ -214,8 +214,9 @@ export function HomePageContent({
toast.error('Failed to create tasks')
}
- // Clear selected repos after creating tasks
+ // Clear selected repos and exit multi-repo mode after creating tasks
setSelectedRepos([])
+ setMultiRepoMode(false)
// Refresh sidebar to get the real task data from server
await refreshTasks()
Analysis
Multi-repo mode not exited after task submission, leaving UI in inconsistent state
What fails: After successfully submitting multi-repo tasks in HomePageContent.handleTaskSubmit(), the multiRepoMode atom remains true while selectedRepos is cleared to []. This leaves the UI showing "Multi-repo" header but displaying "0 repos selected", which is inconsistent and confusing to users.
How to reproduce:
- On the home page, click on the owner selector dropdown
- Select "Multi-repo" option
- Click the "0 repos selected" button to open the multi-repo dialog
- Select 2+ repositories from the dialog and click "Done"
- Submit a task with the selected repositories
- Navigate back to the home page (or check atom state after task submission completes)
Result: The UI displays "Multi-repo" with "0 repos selected" - an inconsistent state. The multiRepoMode atom is true but selectedRepos is empty.
Expected behavior: After multi-repo task submission completes, the multiRepoMode should be reset to false along with clearing selectedRepos, returning the UI to its normal owner/repo selector state.
Root cause: In components/home-page-content.tsx line 218, setSelectedRepos([]) is called after task creation, but setMultiRepoMode(false) is never called. This leaves the state inconsistent.
Fix location: components/home-page-content.tsx lines 216-220
- Changed
multiRepoModefrom read-only (useAtomValue) to read-write (useAtom) - Added
setMultiRepoMode(false)call immediately aftersetSelectedRepos([])to maintain state consistency
No description provided.