fix(dashboard): use proper timestamp for actor status

[jog1t]

TL;DR

Updated actor status determination to use connectableAt instead of startedAt timestamp.

What changed?

• Added connectableAt field to the actor transformation in inspector-data-provider.tsx
• Modified the getActorStatus function to use connectableAt instead of startedAt when determining actor status
• Updated the function parameter type to include the new connectableAt field

How to test?

1. Verify actor status is correctly displayed in the UI for actors in different states
2. Check that actors show the correct status transitions (starting → running → stopped/crashed)
3. Confirm that pending and sleeping states are still properly detected

Why make this change?

The connectableAt timestamp provides a more accurate indicator of when an actor becomes available for connections, making it a better signal for determining the actor's running state than the previously used startedAt field. This change improves the accuracy of actor status reporting in the UI.

[vercel]

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

Project	Deployment	Review	Updated (UTC)
rivet-cloud	Ready	Preview, Comment	Jan 10, 2026 0:05am
rivet-inspector	Ready	Preview, Comment	Jan 10, 2026 0:05am

2 Skipped Deployments

Project	Deployment	Review	Updated (UTC)
rivet-site	Ignored	Preview	Jan 10, 2026 0:05am
rivetkit-serverless	Skipped		Jan 10, 2026 0:05am

[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

• feat(dashboard): provide ns when querying kv #3831 : 2 dependent PRs (#3561 , #3803 )
• chore: update sdks #3830
• refactor: performance improvements for inspector #3452
• fix(dashboard): use proper timestamp for actor status #3809 👈 (View in Graphite)
• fix(engine): require namespace for actor id-specific routes #3828
• 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.

[pkg-pr-new]

More templates

• actor-actions
• example-ai-agent
• example-ai-and-user-generated-actors-freestyle
• chat-room
• example-cloudflare-workers
• example-cloudflare-workers-hono
• example-cloudflare-workers-inline-client
• cross-actor-actions
• example-cursors
• example-cursors-raw-websocket
• custom-serverless
• example-sqlite
• example-elysia
• example-experimental-durable-streams-ai-agent
• hello-world
• example-hono
• hono-react
• example-kitchen-sink
• multi-region
• native-websockets
• next-js
• example-raw-fetch-handler
• example-raw-websocket-handler
• example-raw-websocket-handler-proxy
• example-react
• scheduling
• state
• example-stream
• example-trpc

@rivetkit/cloudflare-workers

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

@rivetkit/db

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

@rivetkit/framework-base

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

@rivetkit/next-js

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

@rivetkit/react

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

rivetkit

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

@rivetkit/sql-loader

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

@rivetkit/virtual-websocket

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/virtual-websocket@3809

@rivetkit/engine-runner

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

@rivetkit/engine-runner-protocol

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

commit: 1848d64

[graphite-app]

Graphite Automations

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

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

[claude]

Code Review - PR #3809: fix(dashboard): use proper timestamp for actor status

Summary

This PR updates the actor status determination logic to use connectableAt instead of startedAt timestamp. This is a focused and appropriate change that improves the accuracy of actor status reporting in the UI.

---

✅ Positive Findings

1. Correct Semantic Change: Using connectableAt is more semantically appropriate for determining when an actor is truly "running" and ready to accept connections, versus startedAt which may only indicate process start.

2. Consistent Implementation: The change is applied consistently across all status determination conditions in the getActorStatus function.

3. Type Safety: The PR properly updates the TypeScript type definition to include connectableAt in the Pick<> type at frontend/src/components/actors/queries/index.ts:111.

4. Data Flow Consistency: Both data providers (engine-data-provider.tsx and inspector-data-provider.tsx) now properly transform and expose the connectableAt field, maintaining consistency across different data sources.

5. Backward Compatible: The optional field pattern (connectableAt?) ensures this won't break for actors that don't have this timestamp set yet.

---

🔍 Issues & Concerns

CRITICAL: Potential Bug in inspector-data-provider.tsx

Location: frontend/src/app/data-providers/inspector-data-provider.tsx:174-176

startedAt: a.createdAt
    ? new Date(a.createdAt).toISOString()
    : undefined,

Issue: The startedAt field is being populated with a.createdAt instead of what appears should be a.startedAt (or removed entirely if not needed). This looks like it might be a copy-paste error or intentional mapping that should be documented.

Questions:

1. Is there a startedAt field available in InspectorActor?
2. If not, should the Actor type still include startedAt?
3. Is the mapping of createdAt to startedAt intentional for the inspector provider?

Recommendation:

• If InspectorActor has a startedAt field, use it: startedAt: a.startedAt ? new Date(a.startedAt).toISOString() : undefined
• If not, and startedAt is genuinely not available from the inspector, consider removing it from the transform or documenting why createdAt is used as a fallback

Compare this with engine-data-provider.tsx:699 which correctly uses a.startTs:

startedAt: a.startTs ? new Date(a.startTs).toISOString() : undefined,

---

🧪 Test Coverage

Missing: No tests were added or modified for the getActorStatus function changes.

Recommendation: Given the critical nature of actor status determination for the UI, consider adding unit tests covering:

• Actors in each status state (starting, running, stopped, crashed, sleeping, pending, crash-loop)
• Edge cases where connectableAt is null/undefined vs when startedAt would have been set
• Transition scenarios (e.g., created → starting → running → stopped)

Example test cases:

// Running state - connectableAt is set
expect(getActorStatus({ 
  createdAt: '2026-01-01T00:00:00Z', 
  connectableAt: '2026-01-01T00:01:00Z',
  destroyedAt: undefined,
  // ... other fields
})).toBe('running');

// Starting state - created but not yet connectable
expect(getActorStatus({ 
  createdAt: '2026-01-01T00:00:00Z', 
  connectableAt: undefined,
  destroyedAt: undefined,
  // ... other fields
})).toBe('starting');

---

📊 Performance Considerations

No performance concerns. The change is a simple field reference swap with no algorithmic complexity changes.

---

🔒 Security Considerations

No security concerns identified. This is purely a UI display logic change.

---

🎨 Code Quality

Strengths:

• Clean, focused change
• Follows existing code patterns
• Proper TypeScript typing

Minor Suggestions:

1. The startedAt field is still in the type but no longer used in getActorStatus - consider if it should be removed from the Pick<> type on line 110 to accurately reflect what's actually used
2. Consider adding a JSDoc comment to getActorStatus explaining the significance of connectableAt vs startedAt for future maintainers

---

📝 Documentation

Missing: No documentation updates explaining:

• The semantic difference between startedAt and connectableAt
• Why this change was necessary
• What connectableAt represents in the actor lifecycle

---

✅ Action Items

Before Merge:

1. ❗ CRITICAL: Investigate and fix the startedAt: a.createdAt mapping in inspector-data-provider.tsx:174-176

Recommended (can be follow-up):

1. Add unit tests for getActorStatus covering all status states
2. Remove startedAt from the Pick<> type if it's truly not needed anymore
3. Add JSDoc comments explaining actor status determination logic

---

🎯 Overall Assessment

This is a good, focused change that improves the accuracy of actor status reporting. The implementation is consistent and type-safe. However, there's a critical issue with the startedAt field mapping in the inspector data provider that should be investigated before merging.

Recommendation: 🟡 Approve with required changes - Address the startedAt mapping issue, then merge.

[graphite-app]

Merge activity

• Jan 12, 9:55 PM UTC: NathanFlurry added this pull request to the Graphite merge queue.
• Jan 12, 9:56 PM UTC: CI is running for this pull request on a draft pull request (#3840) due to your merge queue CI optimization settings.
• Jan 12, 9:56 PM UTC: Merged by the Graphite merge queue via draft PR: #3840.