Skip to content

fix(cloud-agent): dedupe repositories across GitHub installations - #5897

Open
maphew wants to merge 2 commits into
Kilo-Org:mainfrom
maphew:fix/cloud-agent-repo-picker-dedupe
Open

fix(cloud-agent): dedupe repositories across GitHub installations#5897
maphew wants to merge 2 commits into
Kilo-Org:mainfrom
maphew:fix/cloud-agent-repo-picker-dedupe

Conversation

@maphew

@maphew maphew commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

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 by fetchAllGitHubRepositoriesForOrganization) unions the repo lists of every healthy GitHub integration with flatMap and 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 by platformIntegrationId), 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:

  • Prefer the installation whose GitHub account owns the repo, so the session runs with the canonical write identity.
  • Otherwise keep the first entry (integrations arrive newest-first from getIntegrationsByOrganization, created_at desc).

Both consumers of fetchAllGitHubRepositoriesForOrganization (org Cloud Agent and org Code Reviews) are fixed by this single change.

Verification

  • Manual: not run locally — sandbox could not complete pnpm install (V8 OOM on lockfile resolution) to execute Jest; unit tests below cover the regression.
  • Added Jest coverage in github-integration-helpers.test.ts:
    • repo reachable through two installations collapses to the owning account's entry
    • one account with two active installations yields one entry per repo
    • existing per-installation provenance test still passes (distinct repos across accounts unaffected)

Visual Changes

N/A (server-side repo list change; no UI code touched)

Reviewer Notes

  • Dedupe preference is intentionally "owning account first, else newest installation" so a session is prepared against the installation that can always authorize the repo.
  • getIntegrationsByOrganization returns integrations ordered by created_at desc, which makes the first-entry fallback deterministic.

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).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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.

@kilo-code-bot

kilo-code-bot Bot commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

Code Review Summary

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity Count
CRITICAL 0
WARNING 1
SUGGESTION 0
Issue Details (click to expand)

WARNING

File Line Issue
apps/web/src/lib/cloud-agent/github-integration-helpers.ts 211 Fallback keeps the oldest installation, not the newest (getIntegrationsByOrganization is created_at ASC)
Files Reviewed (2 files)
  • apps/web/src/lib/cloud-agent/github-integration-helpers.ts - 1 issue
  • apps/web/src/lib/cloud-agent/github-integration-helpers.test.ts - 0 issues

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 main

# Conflicts:
#	apps/web/src/lib/cloud-agent/github-integration-helpers.test.ts
#	apps/web/src/lib/cloud-agent/github-integration-helpers.ts

maphew commented Sep 9, 2026

Copy link
Copy Markdown
Contributor Author

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 getIntegrationsByOrganization returns oldest-first (it is created_at ASC), matching the primary-installation rule. The same-account dedupe test now feeds installations in DB order and asserts the primary entry is retained. Merge conflict with the #5922 change is resolved.

Verification: targeted web unit suite passes (18 tests).

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.

Cloud Agent repository picker lists repositories multiple times when an org has several GitHub installations

1 participant