This repository was archived by the owner on Aug 6, 2026. It is now read-only.
Repository navigation
feat(code): list all GitHub installations and allow adding another org - #2001
Merged
k11kirky merged 1 commit intoMay 4, 2026
Conversation
This was referenced May 4, 2026
Contributor
Author
k11kirky
marked this pull request as ready for review
May 4, 2026 11:59
Contributor
Prompt To Fix All With AIFix the following 3 code review issues. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 3
apps/code/src/renderer/features/onboarding/components/GitIntegrationStep.tsx:421-426
**Global loading state used per-installation card**
`isLoadingRepos` is a single boolean that is `true` as long as *any* installation's repo query is still pending. When a user has two orgs and one finishes loading before the other, the already-loaded card still displays "Loading…" instead of its actual repo count, because `isLoadingRepos` remains `true` until all queries settle.
A per-installation check would be more accurate — e.g. checking whether `reposByInstallationId[installationId]` is `undefined` (query hasn't resolved yet) vs. an array (already populated).
### Issue 2 of 3
apps/code/src/renderer/features/onboarding/components/GitIntegrationStep.tsx:440-450
**Shared `isConnecting` loading state across all Reconnect buttons**
`isConnecting` is global to the component. When a user clicks "Reconnect" on one stale installation and `handleConnectGitHub()` starts, all other "Reconnect" buttons will also enter a loading state simultaneously. If a user has two stale integrations, clicking Reconnect on one will visually indicate both are in-progress.
### Issue 3 of 3
apps/code/src/renderer/hooks/useIntegrations.ts:162-163
**`reposByInstallationId` not populated for error/loading states**
When a result is in error or still pending, `result.data` is falsy and the function returns early, leaving `reposByInstallationId[installationId]` undefined. In the component this correctly falls back to `[]` for stale installs (which show "Reconnect needed" instead), so the current behaviour is fine. However, it also means you can't distinguish "no repos returned by the API" (empty array) from "query hasn't completed yet" (undefined) at the component level — a distinction that would fix the per-installation loading concern above.
Reviews (1): Last reviewed commit: "feat(code): list all GitHub installation..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Comment on lines
+440
to
+450
| )} | ||
| <Button | ||
| size="1" | ||
| variant="soft" | ||
| color="gray" | ||
| onClick={() => { | ||
| const account = integration.account; | ||
| const url = | ||
| account?.type === "Organization" && | ||
| account.name | ||
| ? `https://github.com/organizations/${account.name}/settings/installations/${installationId}` |
Contributor
There was a problem hiding this comment.
isConnecting loading state across all Reconnect buttons
isConnecting is global to the component. When a user clicks "Reconnect" on one stale installation and handleConnectGitHub() starts, all other "Reconnect" buttons will also enter a loading state simultaneously. If a user has two stale integrations, clicking Reconnect on one will visually indicate both are in-progress.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/code/src/renderer/features/onboarding/components/GitIntegrationStep.tsx
Line: 440-450
Comment:
**Shared `isConnecting` loading state across all Reconnect buttons**
`isConnecting` is global to the component. When a user clicks "Reconnect" on one stale installation and `handleConnectGitHub()` starts, all other "Reconnect" buttons will also enter a loading state simultaneously. If a user has two stale integrations, clicking Reconnect on one will visually indicate both are in-progress.
How can I resolve this? If you propose a fix, please make it concise.
Comment on lines
+162
to
+163
| const installationRepos = result.data.repos ?? []; | ||
| reposByInstallationId[result.data.installationId] = installationRepos; |
Contributor
There was a problem hiding this comment.
reposByInstallationId not populated for error/loading states
When a result is in error or still pending, result.data is falsy and the function returns early, leaving reposByInstallationId[installationId] undefined. In the component this correctly falls back to [] for stale installs (which show "Reconnect needed" instead), so the current behaviour is fine. However, it also means you can't distinguish "no repos returned by the API" (empty array) from "query hasn't completed yet" (undefined) at the component level — a distinction that would fix the per-installation loading concern above.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/code/src/renderer/hooks/useIntegrations.ts
Line: 162-163
Comment:
**`reposByInstallationId` not populated for error/loading states**
When a result is in error or still pending, `result.data` is falsy and the function returns early, leaving `reposByInstallationId[installationId]` undefined. In the component this correctly falls back to `[]` for stale installs (which show "Reconnect needed" instead), so the current behaviour is fine. However, it also means you can't distinguish "no repos returned by the API" (empty array) from "query hasn't completed yet" (undefined) at the component level — a distinction that would fix the per-installation loading concern above.
How can I resolve this? If you propose a fix, please make it concise.
jonathanlab
approved these changes
May 4, 2026
k11kirky
force-pushed
the
05-04-feat_code_detect_stale_github_integration_and_offer_reconnect
branch
from
May 4, 2026 14:14
172b3fe to
c0863fa
Compare
k11kirky
force-pushed
the
05-04-feat_code_list_all_github_installations_and_allow_adding_another_org
branch
from
May 4, 2026 14:14
039bbe6 to
72b415c
Compare
Contributor
Author
k11kirky
changed the base branch from
05-04-feat_code_detect_stale_github_integration_and_offer_reconnect
to
graphite-base/2001
May 4, 2026 15:15
k11kirky
force-pushed
the
05-04-feat_code_list_all_github_installations_and_allow_adding_another_org
branch
from
May 4, 2026 15:29
72b415c to
bf99ac0
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Users with GitHub integrations connected to multiple organizations had no way to manage them individually — the UI only showed a single integration, and disconnect/reconnect actions were scoped to whichever integration happened to be first in the list.
Changes
Connected (N)when more than one integration is active, and "Reconnect needed" is shown when any integration is staleuseUserRepositoryIntegrationnow exposesreposByInstallationIdso each card can display the correct repo count for its installation