fix(cloud-agent): dedupe repositories across GitHub installations - #5897
fix(cloud-agent): dedupe repositories across GitHub installations#5897maphew wants to merge 2 commits into
Conversation
Co-authored-by: kiloconnect[bot] <240665456+kiloconnect[bot]@users.noreply.github.com>
| * accounts that share a repo, or a reinstall left two active installation rows | ||
| * for the same account). Prefer the installation whose GitHub account owns the | ||
| * repository so sessions use the canonical write identity; otherwise keep the | ||
| * first entry, which is the newest installation (created_at desc). |
There was a problem hiding this comment.
WARNING: Fallback keeps the oldest installation, not the newest
getIntegrationsByOrganization orders by created_at ASC, id ASC (oldest first). Promise.allSettled preserves that order, so the first Map entry is the oldest row.
When both installations own the repo (the reinstall case this documents), candidateIsOwner && !existingIsOwner is false and the stale row is kept. The new unit test only passes because it mocks newest-first.
Process integrations newest-first before flattening so the fallback matches the stated newest-installation preference.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
Code Review SummaryStatus: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Files Reviewed (2 files)
Fix these issues in Kilo Cloud Reviewed by grok-4.6 · Input: 153.5K · Output: 12.9K · Cached: 347.9K Review guidance: REVIEW.md from base branch |
# Conflicts: # apps/web/src/lib/cloud-agent/github-integration-helpers.test.ts # apps/web/src/lib/cloud-agent/github-integration-helpers.ts
|
Rebased on main and addressed the review warning. Heads-up: main has since merged #5922 for the same issue, which dedupes by keeping the first (oldest) installation because that is the primary installation a session resolves to. This PR now builds on that behavior instead of contradicting it: the owning account is still preferred when a repo is reachable through several installations, and the fallback keeps the first entry — the comment now correctly says Verification: targeted web unit suite passes (18 tests). |
Summary
Fixes #5887 — when an organization has more than one connected GitHub installation, the Cloud Agent new-thread repository picker (and the Code Reviews repository list, which shares the same helper) lists the same repository once per installation.
fetchRepositoriesForIntegrations(used byfetchAllGitHubRepositoriesForOrganization) unions the repo lists of every healthy GitHub integration withflatMapand no dedupe. A repo reachable through two installations — e.g. the app is installed on two accounts that share a repo, or a reinstall left two active installation rows for the same account — is therefore returned multiple times. The web picker renders each row (keyed byplatformIntegrationId), so the duplicates show up as repeated entries when starting a new thread.The fix deduplicates by repo
fullName(case-insensitive) at the aggregation boundary:getIntegrationsByOrganization,created_at desc).Both consumers of
fetchAllGitHubRepositoriesForOrganization(org Cloud Agent and org Code Reviews) are fixed by this single change.Verification
pnpm install(V8 OOM on lockfile resolution) to execute Jest; unit tests below cover the regression.github-integration-helpers.test.ts:Visual Changes
N/A (server-side repo list change; no UI code touched)
Reviewer Notes
getIntegrationsByOrganizationreturns integrations ordered bycreated_at desc, which makes the first-entry fallback deterministic.