fix(webapp): integrations page follow-ups — build settings visibility, onboarding spinner, dead code - #4786
Conversation
The integrations page wrapped the Git section, the Vercel section and the build settings in a single `githubAppEnabled` guard, so with the GitHub app off the page rendered an empty container. The Vercel section genuinely depends on GitHub - it cannot sync environment variables or link deployments without a connected repo - so it stays inside the guard. Build settings do not: they also apply to CLI deploys run with --native-build-server, exactly as the section describes. They now render regardless. TRI-13488
`computeInitialState` starts in "loading-projects" whenever the org has a Vercel integration but no onboarding data yet. The effect that escapes that state waits for `availableProjects !== undefined`, so when `getOnboardingData` returns null - it does that on any thrown error, and when the org integration row is missing - nothing ever arrives and the modal spins indefinitely with no explanation. The route knows the difference between "still loading" and "loaded nothing", since its fetcher always requests the onboarding data. It now passes that down, and the modal shows what went wrong plus a way to retry or check the integration's access on Vercel. TRI-13488
VercelSettingsPresenter asked for a PREVIEW-typed environment with no filter on the parent, so any preview *branch* row satisfied it - branches are PREVIEW rows too. GitHubSettingsPresenter and ProjectSettingsService ask the same question via the "preview" slug, which only the branchable parent carries, so the two presenters feeding the same page could disagree. All four checks now match on slug. TRI-13488
…on UI Follows the two unreachable panels removed in the parent branch. None of this is reachable either: - The `"installing"` OnboardingState is unproducible - no setState call ever yields it - so its redirect effect, switch arm, isLoadingState conjunct and the vercelAppInstallPath import it was the only user of are all dead. - `(state as string) !== "completed"` is inside a branch where TypeScript has already narrowed "completed" out; the cast is what let it compile. - `hideSectionToggles` was only ever passed alongside layout="settings" but only read inside layout="card" blocks, so it could never take effect. - A handful of unused bindings and the helpers only they referenced: envSlugLabel, _formatSelectedEnvs, _CompleteOnboardingForm, _handleFinishOnboarding and friends. No behaviour change. TRI-13488
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
0ski
changed the title
|
Folded into #4784 — these four commits now live on that branch, so everything ships as a single PR. |
1 participant
Stacked on #4784. Clears TRI-13488, the follow-ups found while fixing James's two tickets.
fix: show build settings when the GitHub app is disabledThe page wrapped Git settings, the Vercel section and build settings in one
githubAppEnabledguard, so with the GitHub app off it rendered an empty container.Item 3 turned out narrower than the ticket described. The Vercel section genuinely depends on GitHub — it can't sync environment variables or link deployments without a connected repo, which is what
VercelGitHubWarningsays — so it stays gated. Build settings don't: they also apply to CLI deploys run with--native-build-server, exactly as the section's own description states. They now render regardless.fix: stop the Vercel onboarding modal spinning forevercomputeInitialStatestarts inloading-projectswhenever the org has a Vercel integration but no onboarding data yet, and the effect that escapes it waits foravailableProjects !== undefined. WhengetOnboardingDatareturnsnull— it does that on any thrown error, and when the org integration row is missing — nothing ever arrives.The empty-array case self-resolves (
[] !== undefined), so this is specifically the null case. The route can tell "still loading" from "loaded nothing" because its fetcher always requests?vercelOnboarding=true; it now passes that down and the modal explains the failure with a retry and a link to check the integration's access on Vercel.fix: match preview environment on slug, not typeVercelSettingsPresenterasked for aPREVIEW-typed environment with no parent filter, so any preview branch row satisfied it — branches arePREVIEWrows too.GitHubSettingsPresenterandProjectSettingsServiceask via the"preview"slug, which only the branchable parent carries, so two presenters feeding the same page could disagree. All four checks now match on slug.chore: remove the remaining dead codeContinues the sweep from the parent branch:
"installing"OnboardingStateis unproducible — nosetStatecall yields it — so its redirect effect, switch arm,isLoadingStateconjunct and thevercelAppInstallPathimport it was the only user of are all dead.(state as string) !== "completed"sits in a branch where TypeScript has already narrowed"completed"out; the cast is what let it compile.hideSectionToggleswas only ever passed alongsidelayout="settings"but only read insidelayout="card"blocks, so it could never take effect. Removed the prop entirely.envSlugLabel,_formatSelectedEnvs,_CompleteOnboardingForm,_handleFinishOnboarding, and the rest.No behaviour change in that commit.
Not included
Per Oskar, the three overlapping modal-open effects in
settings.integrations/route.tsxare left alone — they're defensive against a close-then-reopen race, and untangling them is a behavioural risk with no user-visible payoff.Verification
pnpm run typecheck --filter webapp,pnpm run lintandpnpm run knipare clean, and the four Vercel/project-settings test files pass (39 tests). The onevite.config.tsduplicate-allowedHostserror in my local output is pre-existing and comes from an unrelated branch in my workspace, not this diff.No changeset or
.server-changes/note: the build-settings visibility fix and the spinner fix only bite when the GitHub app is disabled or the Vercel integration has broken, and the rest is internal.refs TRI-13488