fix(dashboard): fetch properly actor counts

[jog1t]

TL;DR

Added actor count query functionality and improved the onboarding experience with better error handling and deployment URL formatting.

What changed?

• Added a new actorsCountQueryOptions function to efficiently query the count of actors
• Updated the frontend setup to use the new actor count query instead of fetching all actors
• Improved actor error display to show crash messages
• Fixed deployment URL formatting by properly extracting the base URL
• Added Posthog tracking for when users skip onboarding
• Enhanced the namespace route to use the new actor count query for determining if actors exist
• Improved error handling in the actor status label component to display more specific crash messages

How to test?

1. Navigate to the getting started flow and verify the actor count is displayed correctly
2. Check that deployment URLs are properly formatted in the frontend setup
3. Trigger an actor crash and verify the error message is displayed correctly
4. Skip onboarding and confirm the Posthog event is captured

Why make this change?

The previous implementation was inefficient as it fetched all actors just to get a count. This change optimizes performance by providing a dedicated endpoint for actor counts. Additionally, the improved error handling and URL formatting enhance the user experience during onboarding by providing clearer feedback and properly formatted links.

[railway-app]

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

Service	Status	Web	Updated (UTC)
website	❌ Build Failed (View Logs)	Web	Jan 17, 2026 at 3:39 am
frontend-inspector	🕒 Building (View Logs)	Web	Jan 17, 2026 at 3:39 am
frontend-cloud	🕒 Building (View Logs)	Web	Jan 17, 2026 at 3:39 am

[jog1t]

• fix(dashboard): fetch properly actor counts #3961 👈 (View in Graphite)
• main

---

How to use the Graphite Merge Queue

Add the label merge-queue to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

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

[graphite-app]

Merge activity

• Jan 17, 3:39 AM UTC: jog1t added this pull request to the Graphite merge queue.
• Jan 17, 3:40 AM UTC: CI is running for this pull request on a draft pull request (#3962) due to your merge queue CI optimization settings.
• Jan 17, 3:41 AM UTC: Merged by the Graphite merge queue via draft PR: #3962.

[graphite-app]

Graphite Automations

"Test" took an action on this PR • (01/17/26)

1 assignee was added to this PR based on Kacper Wojciechowski's automation.

[claude]

PR Review: fix(dashboard): fetch properly actor counts

Summary

This PR optimizes the actor count fetching by introducing a dedicated query function and improves the onboarding UX with better error handling and URL formatting. The changes are solid overall, but there are several areas that need attention.

---

🔴 Critical Issues

1. Performance Issue: Inefficient Actor Count Implementation

Location: frontend/src/app/data-providers/engine-data-provider.tsx:652-685

The new actorsCountQueryOptions function has a major performance problem:

// TODO: fetch all actor names only to get the count is inefficient
const namesList = await client.actorsListNames({
    namespace,
    limit: 100,  // ⚠️ Hardcoded limit
});

const names = Object.keys(namesList.names);

const data = await Promise.all(
    names.map((name) =>
        client.actorsList({
            namespace,
            name,
            limit: 1,
        }),
    ),
);

Problems:

• The limit: 100 on actorsListNames means if there are more than 100 actor names, they won't be counted
• Still fetching individual actor lists for each name (N+1 query problem)
• The TODO comment acknowledges this is inefficient but doesn't address it
• This could cause performance degradation with many actor types

Recommendation: This needs a backend API endpoint that returns just the count (e.g., GET /actors/count). The current implementation is only marginally better than the original. Consider:

1. Adding a dedicated backend endpoint for actor counts
2. If that's not feasible immediately, add pagination handling for actorsListNames to avoid the 100 limit
3. Document this as technical debt if you're shipping as-is

2. Type Safety Issue: Invalid Query Options

Location: frontend/src/app/getting-started.tsx:594-599

const { data: actors } = useQuery({
    ...dataProvider.actorsCountQueryOptions(),
    enabled: (builds?.length || 0) > 0,
    maxPages: 1,  // ⚠️ Invalid option for useQuery
    refetchInterval: 2500,
});

Problem: maxPages is an option for useInfiniteQuery, not useQuery. This should cause a TypeScript error. The query returns a number, not paginated data.

Fix: Remove the maxPages: 1 line.

---

🟡 Significant Issues

3. Missing Error Handling for URL Parsing

Location: frontend/src/app/getting-started.tsx:614-623

const deploymentUrl = useMemo(() => {
    if (!config?.url) return null;
    try {
        const url = new URL(config.url);
        url.pathname = "/";
        return url.toString();
    } catch {
        return null;  // ⚠️ Silent failure
    }
}, [config?.url]);

Issue: The URL parsing error is silently swallowed. If config.url is malformed, users won't know why the deployment button doesn't appear.

Recommendation: Log the error or surface it to the user:

} catch (error) {
    console.warn('Invalid deployment URL:', config.url, error);
    return null;
}

4. Potential Race Condition in useEffect

Location: frontend/src/app/getting-started.tsx:625-643

useEffect(() => {
    const success = async () => {
        successfulBackendSetupEffect();
        router.invalidate();
        return navigate({
            to: ".",
            search: (s) => ({
                ...s,
                onboardingSuccess: true,
            }),
        });
    };
    if (hasActors) {
        success().catch((error) => {
            console.error(error);
        });
    }
}, [hasActors, navigate, router]);

Problem: Missing successfulBackendSetupEffect in the dependency array. While it might be stable, ESLint's exhaustive-deps rule would flag this.

Fix: Either add it to dependencies or wrap it in a ref if it's meant to be stable.

5. Inconsistent Error Message Formatting

Location: frontend/src/components/actors/actor-status-label.tsx:119-121

.with(P.shape({ crashed: P.shape({ message: P.string }) }), (err) => (
    <p>Actor crashed. {err.crashed.message} </p>  // ⚠️ Extra space before closing tag
))

Issues:

• Extra space before the closing </p> tag
• Inconsistent punctuation: "Actor crashed." ends with a period, but the message might also end with punctuation
• No capitalization handling for the crash message

Recommendation:

<p>Actor crashed: {err.crashed.message}</p>

or

<p>Actor crashed. {err.crashed.message}</p>  {/* No extra space */}

---

🟢 Minor Issues / Suggestions

6. PostHog Event Naming Convention

Location: frontend/src/routes/_context/_cloud/orgs./projects./ns..tsx:31

posthog.capture("onboarding_skipped");

Suggestion: Verify this follows your analytics naming conventions. Consider adding context:

posthog.capture("onboarding_skipped", {
    project: params.project,
    namespace: params.namespace,
});

7. Missing Import Cleanup

Location: frontend/src/app/getting-started.tsx:13-17

The PR removed some imports but there might be unused imports remaining. Consider running a linter to clean up.

8. Query Key Consistency

Location: frontend/src/app/data-providers/engine-data-provider.tsx:654

queryKey: [{ namespace }, "actors", "count"] as QueryKey,

Verify this query key structure is consistent with your other query keys in the codebase. Some use arrays of objects, some use flat arrays.

---

✅ Good Practices

1. Proper useMemo usage for the deploymentUrl computation
2. Added PostHog tracking for analytics visibility
3. Improved error messages to show crash details
4. Code consolidation in the namespace route reduces duplication

---

🧪 Testing Recommendations

1. Test with >100 actor names to verify the count limit issue
2. Test with malformed URLs in runner config to verify error handling
3. Verify the crash message displays properly with different error messages (with/without punctuation)
4. Test rapid navigation to check for race conditions in the useEffect
5. Verify PostHog event is captured correctly when skipping onboarding

---

📋 Action Items

Must Fix Before Merge:

1. Remove maxPages: 1 from useQuery call
2. Address the 100 actor name limit in actorsCountQueryOptions

Should Fix:

1. Add error logging for URL parsing failures
2. Fix dependency array in useEffect
3. Remove extra space in error message

Consider:

1. Add backend endpoint for efficient actor counting
2. Add contextual data to PostHog event
3. Run linter to clean up imports

---

Overall Assessment

The PR makes meaningful improvements to the onboarding flow and introduces a dedicated actor count query. However, the implementation still has the performance issue it aims to solve (hardcoded limit + N+1 queries). The changes are functional but need refinement before merge.

Recommendation: Request changes to fix the critical maxPages issue and address the actor count limit.