Skip to content

Conversation

@ctate
Copy link
Collaborator

@ctate ctate commented Dec 3, 2025

No description provided.

@vercel
Copy link
Contributor

vercel bot commented Dec 3, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
coding-agent-platform Ready Ready Preview Comment Dec 3, 2025 11:36pm

Comment on lines +50 to +53
if (response.ok) {
const repos: GitHubRepo[] = await response.json()
return repos.map((repo) => ({ ...repo, owner: owner.login }))
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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:

  1. Open MultiRepoDialog with multiple GitHub owners configured
  2. Configure API endpoint to return 403 Forbidden for at least one owner's repos
  3. 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.

Comment on lines +163 to +229
// 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
Copy link
Contributor

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:

  1. On the home page, click on the owner selector dropdown
  2. Select "Multi-repo" option
  3. Click the "0 repos selected" button to open the multi-repo dialog
  4. Select 2+ repositories from the dialog and click "Done"
  5. Submit a task with the selected repositories
  6. 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 multiRepoMode from read-only (useAtomValue) to read-write (useAtom)
  • Added setMultiRepoMode(false) call immediately after setSelectedRepos([]) to maintain state consistency

@ctate ctate merged commit fd7d691 into main Dec 3, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants