refactor: performance improvements for inspector

[jog1t]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
rivet-inspector	Ready	Preview	Comment	Nov 19, 2025 8:26pm
rivetkit-serverless	Ready	Preview	Comment	Nov 19, 2025 8:26pm

2 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
rivet-cloud	Ignored			Nov 19, 2025 8:26pm
rivet-site	Ignored	Preview		Nov 19, 2025 8:26pm

[jog1t]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• refactor: performance improvements for inspector #3452 👈 (View in Graphite)
• chore(rivetkit): implement new hibernating ws protocol #3464 : 1 other dependent PR (#3487 )
• fix(actor-kv): fix listing keys #3484
• fix(guard): handle actor stopped during ws/req #3481
• chore: rename retry -> hibernate in runner protocol #3473
• fix(udb): update backoff algo #3469
• chore: write/update docs #3468
• chore: add debug scripts #3467
• 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.

[claude]

Code Review - PR #3452: Performance Improvements for Inspector

Overview

This PR is a major refactor focusing on performance improvements for the inspector. The changes involve removing 129 files (9,810 deletions) and adding 988 lines, resulting in a significant simplification and modernization of the frontend codebase.

---

Summary

Strengths:

• ✅ Major cleanup: Removes a large amount of legacy code (129 files deleted)
• ✅ Modernization: Migrates from Jotai atom-based state to React Query data providers
• ✅ Better separation of concerns with dedicated data provider pattern
• ✅ Consistent query/mutation patterns with TanStack Query

Areas for Attention:

• ⚠️ Performance implications of query options need verification
• ⚠️ Missing type safety in some areas
• ⚠️ Potential API call inefficiencies
• ⚠️ Incomplete error handling

---

Detailed Findings

1. Code Quality & Architecture

✅ Good: Data Provider Pattern

The new data provider architecture in default-data-provider.tsx and engine-data-provider.tsx is well-structured:

• Clear separation between default (stub) and engine implementations
• Consistent query/mutation options factory pattern
• Type-safe return types

⚠️ Concern: Query Key Type Safety

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

queryKey: ["namespaces"] as any,

Using as any defeats TypeScript's type checking. Should use proper QueryKey typing:

queryKey: ["namespaces"] as QueryKey,

---

2. Performance Considerations

⚠️ Potential Issue: Refetch Intervals

Location: frontend/src/app/data-providers/default-data-provider.tsx:57, 109

refetchInterval: 2000,  // Line 57
refetchInterval: 5000,  // Line 109

Concern: Different refetch intervals (2s vs 5s) for similar data could cause performance issues:

• The actorsQueryOptions uses 2s refetch
• The actorsListQueryOptions uses 5s refetch
• Both query the same underlying data

Recommendation:

1. Document why different intervals are needed
2. Consider using a WebSocket or Server-Sent Events for real-time updates instead of aggressive polling
3. Make refetch intervals configurable or conditional based on user activity

⚠️ Potential Issue: Query Invalidation Predicate

Location: frontend/src/app/data-providers/default-data-provider.tsx:216-220

queryClient.invalidateQueries({
  predicate: (query) => {
    return keys.every((k) => query.queryKey.includes(k));
  },
});

Concern: This invalidation pattern may be overly broad and invalidate unrelated queries if key naming isn't carefully managed.

Recommendation: Use more specific query key matching or structured query keys.

---

3. Potential Bugs

🐛 Bug: Empty Query Always Returns Empty

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

if (
  (opts?.n?.length === 0 || \!opts?.n) &&
  (opts?.filters?.id?.value?.length === 0 ||
    \!opts?.filters?.id?.value ||
    opts?.filters.key?.value?.length === 0 ||
    \!opts?.filters.key?.value)
) {
  return {
    actors: [],
    pagination: { cursor: undefined },
  };
}

Issue: This logic seems incorrect. The condition returns empty results when:

• No names AND (no ID filter OR no key filter)

This means if you provide an ID filter but no key filter, it still returns empty. This is likely a logic error. Should probably be:

if (
  (\!opts?.n || opts.n.length === 0) &&
  (\!opts?.filters?.id?.value || opts.filters.id.value.length === 0) &&
  (\!opts?.filters.key?.value || opts.filters.key.value.length === 0)
) {
  // Return empty only if ALL are empty

⚠️ Concern: Actor Transformation Missing Null Checks

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

The transformActor function assumes certain fields exist. Consider adding runtime validation or using optional chaining more defensively.

---

4. Missing Error Handling

⚠️ Concern: Generic Error Messages

Location: frontend/src/app/data-providers/default-data-provider.tsx:59, 74, 187, etc.

throw new Error("Not implemented");

While these are stub implementations, ensure that the actual implementations have proper error handling with descriptive messages.

⚠️ Concern: Silent Failures

Location: frontend/src/app/data-providers/engine-data-provider.tsx:92, 93, 151, etc.

retry: shouldRetryAllExpect403,
throwOnError: noThrow,

Using noThrow might hide errors from users. Ensure there's proper error state UI to display these to users.

---

5. Code Style & Best Practices

✅ Good: Consistent Patterns

• Query options follow a consistent naming convention (*QueryOptions)
• Mutation options follow the same pattern (*MutationOptions)
• Good use of TypeScript for type safety (except where noted)

⚠️ Minor: Commented Code

Location: frontend/src/components/actors/actors-actor-details.tsx:150-170, 225-234

Several tabs are commented out (logs, metrics). Consider:

• Removing if permanently disabled
• Adding TODO comments explaining when they'll be re-enabled
• Using feature flags if conditional

---

6. Testing Considerations

Concern: This is a massive refactor (129 files removed, significant architectural changes), but there's no mention of:

• Test coverage for the new data providers
• Integration tests for query/mutation flows
• Migration testing to ensure no regressions

Recommendation:

• Add unit tests for the data provider query/mutation options
• Add integration tests for critical user flows
• Manual testing checklist for regression testing

---

7. Performance Validation

Questions to verify:

1. Has the bundle size changed significantly?
2. What's the impact on initial load time?
3. How many API calls are made on initial page load now vs before?
4. Are there any query waterfalls introduced?

Recommendation: Run performance profiling before/after to validate improvements.

---

Security Concerns

✅ Good: Auth Handling

The mightRequireAuth metadata pattern is good for tracking which queries need authentication.

⚠️ Note: Header Manipulation

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

Object.keys(args.headers || {}).forEach((key) => {
  if (key.toLowerCase().startsWith("x-fern-")) {
    delete args.headers?.[key];
  }
});

Ensure this header removal is intentional and documented. If Fern headers are being stripped for security/privacy, add a comment explaining why.

---

Recommendations

High Priority

1. Fix the query filter logic at engine-data-provider.tsx:230-244
2. Replace as any with proper typing at engine-data-provider.tsx:65
3. Add error handling UI for queries with noThrow
4. Document refetch interval strategy and consider alternatives to aggressive polling

Medium Priority

1. Add unit tests for data provider functions
2. Clean up commented code or add TODO explanations
3. Document the header removal logic
4. Add query key constants to prevent invalidation bugs
5. Validate performance improvements with before/after metrics

Low Priority

1. Consider adding JSDoc comments for complex query options
2. Extract magic numbers (RECORDS_PER_PAGE) to shared constants
3. Add runtime type validation for API responses using Zod

---

Conclusion

This is a solid architectural improvement that modernizes the codebase and should improve maintainability. The removal of Jotai atoms in favor of React Query is a good move for this use case.

However, there are several bugs and performance concerns that should be addressed before merging, particularly:

• The query filter logic bug
• Type safety issues
• Aggressive polling strategy

Overall Assessment: ✅ Approve with recommendations to address the high-priority issues.

Great work on this refactor! The codebase will be much cleaner after this lands. 🚀

[pkg-pr-new]

More templates

• example-ai-agent
• example-background-jobs
• example-better-auth-external-db
• example-bots
• chat-room
• example-cloudflare-workers
• example-cloudflare-workers-hono
• example-counter
• example-counter-serverless
• example-crdt
• example-cursors
• example-cursors-raw-websocket
• example-database
• example-deno
• example-sqlite
• example-elysia
• example-express
• example-freestyle
• example-game
• example-hono
• example-hono-bun
• example-hono-react
• example-kitchen-sink
• example-next-js
• example-rate
• example-raw-fetch-handler
• example-raw-websocket-handler
• example-raw-websocket-handler-proxy
• example-react
• starter
• example-stream
• example-sync
• example-tenant
• example-trpc
• example-workflows

@rivetkit/actor

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/actor@3452

@rivetkit/cloudflare-workers

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/cloudflare-workers@3452

@rivetkit/core

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/core@3452

@rivetkit/db

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/db@3452

@rivetkit/framework-base

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/framework-base@3452

@rivetkit/next-js

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/next-js@3452

@rivetkit/react

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/react@3452

rivetkit

pnpm add https://pkg.pr.new/rivet-dev/rivet/rivetkit@3452

@rivetkit/sql-loader

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/sql-loader@3452

@rivetkit/engine-runner

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/engine-runner@3452

@rivetkit/engine-runner-protocol

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/engine-runner-protocol@3452

commit: 18ed019

[claude]

PR Review: Performance Improvements for Inspector

This PR represents a substantial refactoring that removes 10,090 lines and adds 1,308 lines, achieving a net reduction of ~8,782 lines. The changes focus on cleaning up the actor/inspector component architecture.

✅ Positive Changes

1. Significant Code Reduction: The massive reduction in code complexity is excellent for maintainability. Removing obsolete components and consolidating logic reduces the attack surface and cognitive load.

2. Simplified Data Provider Architecture: The refactoring of data providers (default, engine, inspector) shows better separation of concerns with cleaner query options patterns using TanStack Query.

3. Commented Out Code Pattern: In actor-editable-state.tsx, the entire implementation is commented out rather than deleted. While this might be intentional during migration, it's cleaner to remove dead code entirely (the file can be restored from git history if needed).

4. Query Options Improvements: The new query structure using queryOptions and infiniteQueryOptions follows React Query best practices with proper stale time, retry logic, and error handling.

⚠️ Concerns & Recommendations

1. Missing Type Import (inspector-data-provider.tsx)

Lines 157-173 reference InspectorActor and Actor types that aren't imported. This will cause TypeScript errors:

// Missing imports at top of file:
import type { Actor, InspectorActor } from './types'; // or wherever these are defined

2. Missing Type Definitions (engine-data-provider.tsx)

Line 654 references CrashPolicy type without import:

crashPolicy: a.crashPolicy as CrashPolicy, // Line 654

Add the import:

import type { CrashPolicy } from '@/types'; // adjust path as needed

3. Error Handling in Default Provider

Lines 58-62 in default-data-provider.tsx use throw new Error("Not implemented") followed by unreachable return statements. While the biome-ignore comment acknowledges this, consider using a more type-safe approach:

queryFn: async (): Promise<Rivet.ActorsListResponse> => {
  throw new Error("Not implemented");
}

This makes the return type explicit and removes the unreachable code smell.

4. Authentication Context

Line 22 in engine-data-provider.tsx:

const mightRequireAuth = __APP_TYPE__ === "engine";

Ensure __APP_TYPE__ is properly defined globally (likely in vite config or types). This global reference should be documented or moved to a config file for clarity.

5. Test Coverage

With this much code deletion, verify that:

• All existing tests still pass
• Tests for removed components have been removed or updated
• Critical data provider paths have test coverage

Run: npm test or pnpm test to verify.

6. Dead Code in actor-editable-state.tsx

The entire component implementation (lines 38-122) is commented out. If this feature is temporarily disabled, add a TODO comment explaining why and when it will be restored. Otherwise, delete the commented code:

// TODO(issue-XXXX): Re-enable state editing when backend supports PATCH endpoint
// or
// Remove this file entirely if no longer needed

🔍 Security Considerations

1. Token Handling: The createClient function in engine-data-provider.tsx (lines 35-52) properly handles authentication tokens. Good practice.

2. XSS Prevention: The data transformation functions properly escape/transform API data. No obvious injection vectors.

3. Error Exposure: Error messages don't expose sensitive information - good practice.

🚀 Performance Considerations

1. Query Deduplication: Using TanStack Query with proper queryKey arrays enables automatic deduplication and caching - excellent.

2. Refetch Intervals: Some queries use refetchInterval: 2000 (2 seconds) and refetchInterval: 5000. Consider making these configurable or increasing for production to reduce server load.

3. Pagination: Proper use of initialPageParam and getNextPageParam for infinite queries. The RECORDS_PER_PAGE = 10 constant is reasonable.

📝 Minor Code Style Issues

Following the CLAUDE.md conventions:

1. Import Organization: Imports at top of file ✅ (follows guideline)
2. Structured Logging: N/A for frontend code
3. Hard Tabs: Frontend uses standard formatting (not Rust)

Suggested Action Items

1. ✅ Add missing type imports in inspector-data-provider.tsx
2. ✅ Add missing CrashPolicy type import in engine-data-provider.tsx
3. ⚠️ Clarify or remove commented code in actor-editable-state.tsx
4. ✅ Run full test suite to ensure no regressions
5. ⚠️ Document the __APP_TYPE__ global or move to config

Overall Assessment

LGTM with minor fixes required ✅

The refactoring significantly improves code quality and maintainability. The missing type imports should be fixed before merging, but otherwise this is excellent work. The performance improvements from removing obsolete components and simplifying the data layer are valuable.

Nice work on the substantial cleanup! 🎉

[claude]

Code Review: Performance Improvements for Inspector

Summary

This PR performs a massive cleanup of the frontend codebase, removing 10,090 lines and adding only 1,308 lines (net deletion of ~8,800 lines). The primary focus is on deleting legacy actor management components from frontend/packages/components/src/actors/ and streamlining data providers.

Key Changes

1. Large-Scale File Deletions (70+ files)

The PR removes an extensive set of actor-related UI components, including:

• Actor detail views and tabs (config, connections, logs, metrics, state, console)
• Actor list components and layouts
• Actor creation/management forms
• Actor worker/REPL functionality
• Numerous helper components (status indicators, tags, filters, etc.)

Concern: This is a breaking change that removes significant functionality. The PR title suggests "performance improvements," but this appears to be a feature removal rather than optimization.

2. Data Provider Refactoring

default-data-provider.tsx (new file):

• Creates a clean abstraction layer for data fetching with query options
• Implements proper typing with Zod schemas
• Uses React Query patterns effectively
• Good: Well-structured with consistent patterns

engine-data-provider.tsx (modified):

• Simplified from 696 lines to 686 lines
• Implements the default provider interface
• Adds namespace context management
• Good: Better separation of concerns

3. Commented-Out Code

actor-editable-state.tsx:

export function ActorEditableState({ state, actorId }: ActorEditableStateProps) {
	// return
	// const [isEditing, setIsEditing] = useState(false);
	// ... [entire implementation commented out]
}

actor-clear-events-log-button.tsx:

export function ActorClearEventsLogButton({ actorId }: { actorId: ActorId }) {
	// const { mutate, isPending } = useActorClearEventsMutation(actorId);
	return null;
	// ... [entire implementation commented out]
}

Critical Issue: Multiple components are gutted with their implementations commented out. This is not production-ready code.

Issues & Concerns

🔴 Critical Issues

1. Commented-Out Code: Several files contain entirely commented-out implementations that just return null. This is a code smell and suggests incomplete work:

   • actor-editable-state.tsx
   • actor-clear-events-log-button.tsx

2. CI Failures: All TypeScript checks are failing:

   • tsc: FAILURE
   • quality: FAILURE
   • publish: FAILURE
   • Vercel deployments for rivet-inspector and rivetkit-serverless: FAILURE

3. Breaking Changes: The massive deletion of components will break:

   • Any code importing these deleted components
   • User workflows depending on these features
   • Integration tests (if they exist)

4. Missing Description: The PR has no description explaining:

   • What performance improvements are being made
   • Why these files are being removed
   • What functionality is being preserved/replaced
   • Migration path for affected code

⚠️ Major Concerns

1. Unclear Performance Impact: Despite the title "performance improvements for inspector," it's unclear:

   • What performance metrics improved
   • What was causing performance issues
   • How removing these components improves performance
   • Whether this is bundle size optimization or runtime performance

2. No Test Coverage Verification: With such extensive deletions, there's no evidence of:

   • Updated tests
   • Removed tests for deleted functionality
   • Integration test updates

3. Import Path Changes: Files like actor-database.tsx show changes in how types are imported, but without seeing the full diff context, it's hard to verify all references are updated.

💡 Minor Issues

1. Type Assertions: In engine-data-provider.tsx:636-659, the transformActor function performs several unsafe transformations without validation.

2. Query Key Typing: Using as QueryKey and as any type assertions suggests loose typing that could cause runtime issues:

   queryKey: ["namespaces"] as any,  // Line 65

3. Error Handling: Several query functions use noThrow and shouldRetryAllExpect403 without clear documentation of error states.

Recommendations

Before Merging

1. Fix CI Failures: All TypeScript compilation errors must be resolved
2. Remove or Implement Commented Code: Either remove the gutted components or implement them properly
3. Add PR Description: Explain the "why" behind these changes
4. Verify Breaking Changes: Ensure no existing code depends on deleted components
5. Add Tests: Verify test coverage for remaining functionality

Code Quality

1. Remove Type Assertions: Replace as any and excessive as QueryKey with proper typing
2. Add Error Boundaries: The new data provider should handle errors gracefully
3. Document Performance Gains: Add metrics/benchmarks showing the performance improvements
4. Migration Guide: If this removes user-facing features, provide migration documentation

Architecture

1. Feature Flags: Consider using feature flags for such large-scale removals
2. Incremental Rollout: Breaking this into smaller PRs would be safer
3. Deprecation Path: Mark features as deprecated before removal

Security Considerations

No security issues identified. The changes are primarily structural and don't introduce obvious vulnerabilities.

Performance Considerations

Potential Positives:

• Smaller bundle size (~8,800 lines removed)
• Fewer React components to load
• Simplified data fetching layer

Unknown:

• Runtime performance impact
• Whether removed features are replaced by more efficient alternatives
• Actual metrics on performance improvements

Verdict

❌ NOT READY FOR MERGE

This PR has failing CI checks, commented-out code, and no description explaining the changes. While the code cleanup appears well-intentioned, it needs significant work before merging.

Must Fix Before Merge:

1. ✅ Resolve all TypeScript compilation errors
2. ✅ Remove or properly implement commented-out code
3. ✅ Add comprehensive PR description
4. ✅ Verify no breaking changes to existing features
5. ✅ Update or remove related tests

Recommended Improvements:

• Add performance benchmarks/metrics
• Consider breaking into smaller, focused PRs
• Add migration guide if removing user-facing features
• Improve type safety (remove as any assertions)

---

Reviewed by: Claude Code
Note: This is an automated review. Please verify all findings with human review.