refactor(frontend): modify onboarding for rivet compute

[jog1t]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[jog1t]

• refactor(frontend): runner_pool -> rivet_pool #5107
• refactor(frontend): modify onboarding for rivet compute #5106 👈 (View in Graphite)
• fix(frontend): align log region column and disable selection on metadata #5105
• fix(frontend): clickable namespaces in deployments table #5104
• fix(fontend): less monoscaped #5103
• fix(frontend): meaningful serverless metadata errors #5102
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[jog1t]

Merge activity

• May 26, 10:23 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• May 26, 10:33 PM UTC: Graphite rebased this pull request as part of a merge.
• May 26, 10:33 PM UTC: @jog1t merged this pull request with Graphite.

[claude]

Code Review

frontend/src/app/data-providers/cloud-data-provider.tsx

Missing staleTime (and gcTime) on the new query options

Every other polling/refetch query in this file that uses refetchInterval also sets staleTime (and usually gcTime). The new currentProjectFirstImagePresentQueryOptions sets only refetchInterval: 5000 with no staleTime. Without it, React Query treats the cached value as immediately stale on every mount, triggering a background refetch even when data is fresh from a moment ago. Recommend adding staleTime: 4000 (just under the poll cadence) and gcTime: 5 * 60 * 1000 to match the file's existing convention.

Query key structure differs from the sibling

currentProjectImagesQueryOptions stores the org/project inside an opts object as [opts, "images"], following the file's general keying convention. The new currentProjectFirstImagePresentQueryOptions uses a flat array [organization, project, "images", "first-present"]. This inconsistency means React Query cannot share or correctly invalidate the two keys together. Recommend using the same structural pattern, e.g. [{ organization, project }, "images", "first-present"] — or confirming the independence is intentional and adding a brief comment.

Comment describes what, not why

The block comment before currentProjectFirstImagePresentQueryOptions re-describes what the function name and refetchInterval already make obvious. Per the repo's conventions, comments should capture non-obvious constraints or invariants. The one detail worth preserving is why this is a separate query key from currentProjectImagesQueryOptions (dedicated polling interval, returns a boolean). Everything else can be removed.

---

frontend/src/app/getting-started.tsx

Brief flash of wrong message on initial render

When enabled is true but the first fetch has not yet resolved, hasImage is undefined. Because undefined !== true is true, the component renders "Waiting for your first deployment..." before it has confirmed no image exists. A user who already has images will briefly see the wrong message before the query returns. Adding placeholderData: false (or an isLoading guard) would default the initial render to the correct copy.

Noop fallback object recreated on every render

The inline object { queryKey: ["frontend-setup", "first-image-noop"] as const, queryFn: () => false } is constructed fresh on each render pass. While React Query does stable-compare query keys, the queryFn function reference changes every render. Extract this to a module-level constant so object identity is stable:

const FIRST_IMAGE_NOOP_QUERY = {
  queryKey: ["frontend-setup", "first-image-noop"] as const,
  queryFn: () => false,
} as const;

---

frontend/src/lib/data.ts

Duplicate traversal of the same nested structure

provider and hasConfiguredDatacenter both walk the same three-level runnerConfigs -> datacenters nesting and call deriveProviderFromMetadata. A single pass is cleaner and avoids diverging if the logic ever changes:

const allDcProviders = (runnerConfigs?.pages ?? [])
  .flatMap((page) =>
    Object.values(page.runnerConfigs).flatMap((config) =>
      Object.values(config.datacenters).map((dc) =>
        deriveProviderFromMetadata(dc.metadata),
      ),
    ),
  )
  .filter((p): p is string => p !== undefined);

const provider = allDcProviders[0];
const hasConfiguredDatacenter = allDcProviders.length > 0;

Asymmetric paging logic

hasRunnerNames only looks at pages[0], while hasConfiguredDatacenter uses .some(page => ...) across all pages. If both are meant to be exhaustive checks, hasRunnerNames should also iterate all pages.

---

Overall

The core logic is sound. Gating hasBackendConfigured on metadata.provider presence is a clear improvement over the previous any-config check that would incorrectly advance users past the onboarding step when a compute pool existed but was not yet provider-tagged. The image-polling hook correctly short-circuits to a no-op in non-cloud builds via the features.compute gate.

The items most likely to affect runtime behavior: the missing staleTime on the new polling query, the initial-render flash showing the wrong message for users who already have images, and the paging asymmetry in hasRunnerNames.