feat(frontend): compute ui

[abcxff]

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

[railway-app]

🚅 Deployed to the rivet-pr-5084 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
website	✅ Success (View Logs)	Web	May 22, 2026 at 9:54 pm
frontend-cloud	😴 Sleeping (View Logs)	Web	May 21, 2026 at 12:17 am
frontend-inspector	❌ Build Failed (View Logs)	Web	May 21, 2026 at 12:09 am
ladle	✅ Success (View Logs)	Web	May 21, 2026 at 12:07 am
mcp-hub	✅ Success (View Logs)	Web	May 21, 2026 at 12:06 am
kitchen-sink	❌ Build Failed (View Logs)	Web	May 21, 2026 at 12:06 am

[abcxff]

• feat(frontend): compute ui #5084 👈 (View in Graphite)
• main

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

[claude]

Code Review: feat(frontend): compute ui

PR State: Draft | Files: 8 | +378 / -325

Overall this is a solid re-enablement of the compute UI that was previously commented out. The scroll restoration fix is particularly well-reasoned. A few issues worth addressing before merging.

---

Warnings

1. Duplicate managedPool query in ActorsGrid

ActorsGrid runs currentProjectManagedPoolQueryOptions at the top level to gate the Logs button, and DeploymentsSection (rendered inside the same component) runs the same query independently. While React Query deduplicates in-flight requests, the result is two separate useQuery calls reading the same key. The hasCompute state in ActorsGrid and hasPool in DeploymentsSection are logically the same value. Consider lifting the single query into ActorsGrid and passing hasPool as a prop to DeploymentsSection.

2. Suspicious limit: 1 on the full deployments page

// deployments.tsx
const { data: images, ... } = useSuspenseInfiniteQuery({
    ...dataProvider.currentProjectImagesQueryOptions({ limit: 1 }),
    refetchInterval: 5_000,
});

On the dedicated /deployments route where the user expects to see all images, the page size is 1. This likely causes "Load more" to appear immediately after the first item. The summary grid in actors-grid.tsx correctly uses limit: 5 for its preview, but the full-page view should omit the limit or use the default. This looks like a copy-paste bug.

3. Scroll restoration timing: prevTotalSizeRef may not reflect new item sizes in the RAF

// deployment-logs.tsx
scrollOffsetBeforeLoadRef.current = instance.scrollOffset ?? 0;
prevTotalSizeRef.current = instance.getTotalSize();
loadMoreHistory();
// ... then in RAF:
const addedHeight = newTotalSize - prevTotalSizeRef.current;

Because TanStack Virtual updates item sizes asynchronously via ResizeObserver, the RAF may fire before newly prepended items are measured — making addedHeight zero and the scroll anchor doing nothing. This is an improvement over the index-based approach in the common case but may produce occasional flickers on slow machines. Worth a comment noting the timing limitation.

4. hasMore threshold is off-by-one in DeploymentsSection

const hasMore = sorted.length >= 5;

If exactly 5 images are returned (a full last page with no more items), this shows "View all" incorrectly. The component already uses an infinite query — destructure hasNextPage from the result and use it instead:

const { data: images, hasNextPage } = useInfiniteQuery(...);
const hasMore = hasNextPage;

---

Minor Suggestions

5. Empty <p> tag in logs.tsx

<p className="mb-6 text-muted-foreground"></p>

This renders an empty paragraph with mb-6 margin below the heading. Looks like description text was removed but the tag was left behind — either remove it or fill it.

6. Double space in TroubleshootingSection className (getting-started.tsx)

<AccordionContent className="px-4 py-2  rounded-md border">

Two spaces between py-2 and rounded-md.

7. justify-between with a single child (deployments.tsx and logs.tsx)

After HelpDropdown was removed, the flex container in the page headers has justify-between but only one child. Consider removing the class or simplifying the layout.

8. Hardcoded "rivet" string for special-case layout (getting-started.tsx)

className={option.name === "rivet" ? "col-span-2 py-5" : undefined}

Fragile if the provider name changes. Prefer an isWide?: boolean field on DeployOption or checking against deployOptions[0].name.

9. maxConcurrentActors halved without explanation (getting-started.tsx)

The default went from maxCount: 100_000 to maxConcurrentActors: 50_000. If this is an intentional policy change, a brief note in the PR description would clarify it.

---

Confirmed Good

• Re-enabling imagesQueryOptions with optional limit is clean. The queryKey includes opts so different limit values produce separate cache entries correctly.
• The refetchInterval adaptive logic (query.state.data === null ? false : 5_000) is a good optimization to avoid hammering 404 endpoints.
• The safe: true pattern on pool queries to avoid throwing on 404 is used consistently.
• Extracting TroubleshootingSection from FrontendSetup is a clean refactor.
• The useCloudProjectDataProvider fix in images-table.tsx is correct — currentProjectNamespaceQueryOptions is a project-level query.
• Logs/deployments empty-state guards include a back-link — good UX.