ref(repos): Refactor useOrganizationRepositoriesWithSettings to use apiOptions & useInfiniteQuery

[ryan953]

This brings in useInfiniteApiQuery to replace useFetchSequentialPages inside of useOrganizationRepositoriesWithSettings

The idea is that this will be a better foundation to use to continue to iterate on the pages that load up lists of repos (there's a seer wizard step, and also the org settings page).

I believe that the new system is a bit slower to run on orgs that have 1,000's of repos. It's because we're loading and rendering each chunk of data using react to trigger the next chunk. I like it better however because we return a proper queryResult object that useQuery knows how to keep track of. The benefit is that we can re-fetch the data instead of it being cached inside the state inside useFetchSequentialPages. Also, I'm following up with virtual rendering which will counteract the re-render penalty.

[cursor]

Infinite query not invalidated after repository mutations

Medium Severity

After bulk repository settings updates, only individual repository queries are invalidated via getRepositoryWithSettingsQueryKey, but the infinite query created by organizationRepositoriesInfiniteOptions is not invalidated. This causes the repository list to show stale settings data (like enabledCodeReview status) until the page is refreshed or the cache expires. The old useFetchSequentialPages implementation didn't need invalidation because it stored data in component state, but React Query caches require explicit invalidation.

 

[ryan953]

This is true, we have the weird mutationData stuff in there now to overcome this.

I'll revisit once #108798 is merged and we have faster rendering cycles.

[cursor]

Select function recreated on every render

Low Severity

The select function passed to useInfiniteQuery is defined inline without memoization, causing it to be recreated on every render. This forces the select function to re-run on every render even when the underlying data hasn't changed, performing expensive operations like uniqBy, filter, toSorted, and flatMap unnecessarily. This is particularly problematic when auto-fetching multiple pages, as each page fetch triggers additional re-renders.

Additional Locations (1)

• static/gsApp/views/seerAutomation/onboarding/hooks/seerOnboardingContext.tsx#L102-L107

 

[ryan953]

this fn depends on sort, so that's something to revisit.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

Loading spinner persists when results are empty

Medium Severity

The hasData variable (derived from repositories.length > 0) is used to control the mini LoadingIndicator, but it reflects data presence rather than loading state. When loading completes with zero results (e.g., a search term that matches nothing), hasData remains false, so the spinner shows permanently alongside the "No repositories found" message. The isLoading and isLoadingMore props are already available in RepoTable but aren't used for this check.

Additional Locations (1)

• static/gsApp/views/seerAutomation/components/repoTable/seerRepoTable.tsx#L220-L221