fix(integrations): expose stored service-account catalog connections - #7624
Open
BillLeoutsakosvl346 wants to merge 8 commits into
Open
fix(integrations): expose stored service-account catalog connections#7624BillLeoutsakosvl346 wants to merge 8 commits into
BillLeoutsakosvl346 wants to merge 8 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
 The PR appears safe to merge; the previously reported connection-routing issues are resolved and no actionable new failure remains.
|
`ServiceAccountIntegrationMatch` named a service-account integration but left its icon to a second `resolveOAuthServiceForSlug` lookup, which is null for a stored-credential integration whose catalog entry is not `oauth`. The chat's inline connect control read the icon from that lookup, so `useServiceAccountConnectTarget` saw an undefined icon and rendered nothing for exactly the four integrations this branch exposes. Resolving the icon once, where the match is built, removes the second lookup and the class of bug with it. Also: - Offer the service-account connect control while deployment availability is still unknown, matching `oauthAvailable` directly above it. A pessimistic default rendered a disabled "Unavailable" verdict for the whole permission-config load on an integration whose only path is a stored service account. - Drop the `listCredentialProviderCatalog` case that mocked `createIntegrationCredentialVisibility` wholesale: it asserted catalog wiring that did not change and passed without the fix. The projection and both `requireAvailableServiceAccountCredentialProvider` branches are already covered in this file. - Move the new visibility case below the `beforeEach` that configures it, and set the block mock through `mockImplementation` like its neighbours instead of relying on hook ordering to undo a `mockReturnValue`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V9K4apTYamQFpRYT3tcjVQ
Collaborator
Collaborator
|
@cubic-dev-ai review this PR |
Contributor
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
Every new case in this branch was parameterized on the service id, which made Claude Platform quietly absent from all of them: its block type is `managed_agent`, so a serviceId-keyed lookup finds no availability entry and no allowlist key. Pair each case with its block type and add the fourth integration, so the authorization tightening and the availability projection are pinned for all four rather than three. Also: - Guard the icon the previous commit added to `ServiceAccountIntegrationMatch`. It had no test, and its absence renders nothing at all rather than a broken chip, so the gap was invisible in exactly the way that produced the bug. - Assert `isDeploymentGatedIntegrationType` for the four, alongside the unconditional `ready` that keeps the gate from hiding them. - Narrow the connect-control's unknown-availability default to the case it was written for. Relaxing it for every integration widened the header control from a chip to a dropdown and back on every OAuth integration that also offers a service account, as the permission config landed. - Read `atlassianProduct` from the service-account match that mounts the modal rather than the OAuth match, which is null for a stored-credential integration. Verified behavior-identical across all 39 integrations that can mount it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V9K4apTYamQFpRYT3tcjVQ
Collaborator
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
…oint Three surfaces decided whether to offer a connect flow by asking whether the integration was `authType: 'oauth'`, which is false for one authenticated by a stored service account. Each failed differently. Suggested actions was the worst of them, and the failure predates this branch: `defineServices` enumerates every OAuth provider, including the four whose `authType` is `service_account`, so "Integrate with Snowflake" was already offered on the home screen — and clicking it resolved no OAuth target and fell off the end of the handler. Snowflake, NetSuite, Harmonic and GitHub all had dead rows. They now hand off to the integration's detail page, carrying the service-account deep link when that is the flow on offer, so the modal still opens in one click. Sidebar search needed both halves fixed to work: the `authType` gate dropped the deep link, and the mode callback matched on the `limited` state an OAuth integration reaches when only its service account is available. An integration whose *only* credential is a service account is plain `ready`, so it fell through to `null`. Gate on having a credential service and test what is actually connectable instead. The detail page reserved "Unavailable" for a verdict it had no business making: an API-key integration still runs on the user's own key, so it now keeps the catalog's ordinary call to action, which also collapses a duplicated fallback branch. The catalog card is deliberately left alone — its `authType === 'oauth'` guard is what stops it from calling a usable block unavailable, and it was the detail page that diverged. Also fail open on a *failed* availability fetch rather than a pending one, per review: while the config is in flight the answer is imminent and an optimistic default would flip the header control's shape, but once both queries settle with nothing the request failed, and withholding the control strands a user who has a valid stored account behind a fetch they cannot retry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V9K4apTYamQFpRYT3tcjVQ
Collaborator
…known The search deep link fell back to OAuth whenever deployment availability could not be read — while it loads, and after a failed fetch. That was safe while only OAuth integrations reached the fallback, but this branch also routes stored-service-account ones through it, and they have no OAuth flow for the detail page to open: the link resolved to nothing and cost the search result the one click it exists to save. Carry the catalog's own answer instead. `getConnectMode` now receives it and returns it verbatim when it cannot do better, which also keeps `null` meaning what it meant — the deployment offers no connect flow — rather than doubling as "unknown". Covers the builder, which had no tests: the per-credential-kind deep link, the resolver contract, and the allowlist filter. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V9K4apTYamQFpRYT3tcjVQ
Collaborator
The page this branch exists to fix had no tests, and its header action is the branch's whole user-visible surface: five integration classes crossed with a loading, loaded and failed availability answer, expressed as nested ternaries. Covers the decision for both classes that matter — one whose only credential is a stored service account, and one that also offers OAuth — across all three availability states, plus the two "Unavailable" cases in either direction. The control-kind tag in the helper is load-bearing. A `ChipDropdown` trigger renders the same "Add to Sim" placeholder as the plain chip, so an assertion on label text alone cannot tell one connect option from two, and the case guarding the narrowed unknown-availability default passed against the over-broad version it was written to reject. Tagging on `aria-haspopup` makes it fail. Each of the six cases was checked against a mutation of the behavior it describes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V9K4apTYamQFpRYT3tcjVQ
Collaborator
Collaborator
BillLeoutsakosvl346
force-pushed
the
fix/platform-service-account-catalog
branch
from
September 10, 2026 17:54
a60783e to
629f201
Compare
Contributor
Author
|
Accidentally made a small change here while reviewing some other recent PRs I did, I reverted it |
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
Verification
Generated changes are limited to four catalog relationships and their four provider projections. No credentials, real customer data, or live provider requests are included.