fix(web): GitHub companion repo search + re-claim site on report open#4439
Merged
o-pauloroberto merged 3 commits intoJul 13, 2026
Merged
Conversation
Add GitHub as an optional data-source companion on the commerce diagnostic onboarding screen, reusing the existing companion OAuth flow (deco/mcp-github) — same design and behavior as GA4/GSC/VTEX. Connecting is never required, so a client who doesn't want to share code never blocks the analysis. - companions.ts: register the `github` companion card - github-config-form.tsx: post-connect repo picker (lists repos via GITHUB_LIST_USER_ORGS + search_repositories) that saves the chosen owner/name as `github_repo` on the Commerce Discovery connection — the field the repo-audit skill reads at run time - registry.ts / query-keys.ts: register the form and its query key The card is schema-driven: it surfaces once Commerce Discovery declares the `github` binding (companion PR in decocms/commerce-discovery), which also leases the client's token server-side for the repo-audit skill.
Two commerce-onboarding fixes found while debugging on staging: 1. GitHub repo picker missed repos (e.g. deco-sites/fila-store). It fetched only page 1 (50 items) of search_repositories per org, and GitHub's "best match" order drops most repos of a large org (deco-sites has 600+). Replace the fixed list with a debounced server-side search that passes the typed term as `in:name`, plus a manual owner/name fallback so any repo is always selectable. (SelectableList gains an optional `hideSearch` so the form can drive filtering itself.) 2. A returning org opening the onboarding for a DIFFERENT site than the one its Commerce Discovery connection was last claimed for showed the previous site's report (the per-org connection token is claimed per-site). setupReady now requires the connection to be claimed for the requested site; otherwise it re-runs setup (idempotent re-claim). openReport also stops navigating when COMMERCE_DISCOVERY_RUN returns triggered:false (not_upgraded), which would otherwise render the wrong store's diagnostic.
pedrofrxncx
approved these changes
Jul 11, 2026
| * 600+). Passing the typed query as an `in:name` filter is what makes an | ||
| * arbitrary repo findable — this is the fix for repos that never appeared. | ||
| */ | ||
| async function searchRepos( |
Collaborator
There was a problem hiding this comment.
pls make sure that we warn the user if the search fails/timeouts, instead of just returning empty result
…ng-repos-and-site-claim # Conflicts: # apps/mesh/src/web/lib/query-keys.ts # apps/mesh/src/web/routes/commerce-onboarding/companion-forms/github-config-form.tsx
decocms Bot
pushed a commit
that referenced
this pull request
Jul 13, 2026
PR: #4439 fix(web): GitHub companion repo search + re-claim site on report open Bump type: patch - decocms (apps/mesh/package.json): 4.11.13 -> 4.11.14 Deploy-Scope: web
pedrofrxncx
added a commit
that referenced
this pull request
Jul 13, 2026
…eUrl param (#4483) The site-match check added in #4439 (re-claim the connection when the requested site differs from the one it's currently claimed for) bypassed itself whenever normalizeCommerceSiteUrl failed — which happens both for an empty requestedSite (intentional: no site requested, trust the existing claim) and for a non-empty but malformed one (unintentional). A garbled ?siteUrl query param therefore skipped re-claiming and skipped the COMMERCE_DISCOVERY_RUN trigger, opening whatever site the connection happened to already be claimed for instead of surfacing the invalid-URL error the rest of the component already handles. Extracted the check into isConnectionClaimedForSite so "no site requested" and "invalid site requested" are distinguished explicitly, and added a regression test for the malformed-but-non-empty case.
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.
Two commerce-onboarding bugs found while debugging on staging (
studio-stg) with Chrome DevTools. Follow-up to the merged GitHub companion (#4431).Bug 1 — GitHub repo picker missed repos (e.g.
deco-sites/fila-store)The picker fetched only page 1 (
perPage: 50) ofsearch_repositoriesper org. GitHub orders results by "best match", so most repos of a large org are silently dropped —deco-siteshas 623 repos, andfila-storewasn't in the top 50 (whileaviatorwas). Client-side filtering can't find what was never fetched.Fix: debounced server-side search that passes the typed term as an
in:namefilter (verified live:org:deco-sites fila-store in:name→ returns exactlydeco-sites/fila-store), plus a manualowner/namefallback so any repo is always selectable.SelectableListgains an optionalhideSearchprop so the form drives filtering itself.Bug 2 — wrong store's report (returning org opened another site's diagnostic)
The Commerce Discovery connection is per-org but its token is claimed per-site (
setup→/upgrademints a site-scoped token and persists it). A returning org that opened the onboarding for a different site than the one last claimed rendered the previous site's report.Observed on staging: org
decohadmetadata.siteUrl = https://montecarlo.com.br; opening?siteUrl=aviator.com.brdid not callCOMMERCE_DISCOVERY_SETUP(becausesetupReadywas already true),COMMERCE_DISCOVERY_RUN(aviator)returned{triggered:false, reason:"not_upgraded"}, andopenReportnavigated anyway → the Monte Carlo report rendered under the Monte Carlo token.Fix:
setupReadyis true only when the existing connection is claimed for the requested site; otherwise the page falls through tosetup(idempotent re-claim), so the token +metadata.siteUrlfollow the site being onboarded.openReportno longer navigates whenCOMMERCE_DISCOVERY_RUNreturnstriggered:false(not_upgraded) — it surfaces an error instead of showing the wrong store's diagnostic.Files
companion-forms/github-config-form.tsx— server-side repo search + manual fallbackcompanion-forms/selectable-list.tsx— optionalhideSearchlib/query-keys.ts— search-term + selected-repo keyscommerce-onboarding.tsx— site-awaresetupReady+openReportguardTesting
tsc+oxlintclean.fila-store).Summary by cubic
Fixes the GitHub repo picker to reliably find any repo and ensures the Commerce Discovery report opens for the requested site. Prevents missing repos in large orgs and avoids showing the wrong store’s report.
in:name, with per-account timeouts and partial-failure warnings. Added manualowner/namefallback and always show the currently selected repo.SelectableListsupportshideSearch, and queries are keyed by search term; a separate key reads the prefilled selected repo.setupReadyis true only when the connection is claimed for the requested site; otherwise setup re-claims it.openReportstops navigation on runs that aren’t triggered (not_upgraded) and shows an error.Written for commit bf765f7. Summary will update on new commits.