fix: workflow statuses

[jog1t]

Description

This pull request improves the workflow visualizer component with several enhancements and bug fixes. The changes include reorganizing imports for better readability, fixing the default status logic for workflow entries (changing from "pending" to "completed" when no explicit status is provided), correcting the retry count display to show actual attempts rather than retry attempts, and enhancing the ReactFlow interaction model by disabling node dragging, edge reconnection, and pan activation key while enabling full pan on drag functionality.

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]

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: refetch actor details every 5s #4306
• fix: missing context switcher for engine #4305
• feat: allow ips in runner configs #4304
• fix: workflow statuses #4303 👈 (View in Graphite)
• refactor: tabs visibility #4302
• fix: workflow visualizer styles #4301
• fix: disable selection on drag #4300
• fix: pkg pr new config #4299
• fix: invalid changelog ping position #4298
• fix: inspector dev env #4297
• 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
• actor-actions-vercel
• ai-agent
• ai-agent-vercel
• example-ai-and-user-generated-actors-freestyle
• chat-room
• chat-room-vercel
• example-cloudflare-workers
• example-cloudflare-workers-hono
• collaborative-document
• collaborative-document-vercel
• cross-actor-actions
• cross-actor-actions-vercel
• example-cursors
• example-cursors-raw-websocket
• example-cursors-raw-websocket-vercel
• example-cursors-vercel
• custom-serverless
• example-elysia
• example-experimental-durable-streams-ai-agent
• example-experimental-durable-streams-ai-agent-vercel
• geo-distributed-database
• geo-distributed-database-vercel
• hello-world
• hello-world-vercel
• example-hono
• hono-react
• hono-react-vercel
• example-kitchen-sink
• example-kitchen-sink-vercel
• multi-region-vercel
• multiplayer-game
• example-multiplayer-game-patterns
• example-multiplayer-game-patterns-vercel
• multiplayer-game-vercel
• native-websockets
• native-websockets-vercel
• next-js
• per-tenant-database
• per-tenant-database-vercel
• example-raw-fetch-handler
• example-raw-fetch-handler-vercel
• example-raw-websocket-handler
• example-raw-websocket-handler-proxy
• example-raw-websocket-handler-proxy-vercel
• example-raw-websocket-handler-vercel
• example-react
• example-react-vercel
• sandbox
• sandbox-coding-agent
• sandbox-coding-agent-vercel
• sandbox-vercel
• scheduling
• scheduling-vercel
• example-sqlite-drizzle
• example-sqlite-raw
• state
• state-vercel
• example-stream
• example-stream-vercel
• example-trpc

@rivetkit/cloudflare-workers

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

@rivetkit/framework-base

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

@rivetkit/next-js

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

@rivetkit/react

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

rivetkit

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

@rivetkit/sql-loader

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

@rivetkit/sqlite-vfs

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/sqlite-vfs@4303

@rivetkit/traces

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

@rivetkit/workflow-engine

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/workflow-engine@4303

@rivetkit/virtual-websocket

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

@rivetkit/engine-runner

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

@rivetkit/engine-runner-protocol

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

commit: 19554df

[claude]

PR Review: fix: workflow statuses

Summary

This PR touches three files in the workflow visualizer and makes four distinct changes: import reorganization, a status fallback fix, a retry count display fix, and ReactFlow interaction model improvements.

---

Issues

1. Potentially Incorrect Status Fallback (workflow-to-xyflow.ts:118)

Concern: The most significant logic change is the fallback status when rawStatus, startedAt, and completedAt are all absent:

Before: rawStatus || (completedAt ? "completed" : startedAt ? "running" : "pending")

After: rawStatus || (completedAt ? "completed" : startedAt ? "running" : "completed")

If an entry has no timestamps and no explicit status, the new code defaults it to "completed". But "pending" would seem more semantically correct for an entry that has no record of having started. Consider a partially-executed workflow where future steps don't yet have timestamps — those entries would now falsely appear as completed in the visualizer.

The PR description states this is a bug fix, implying the backend sometimes emits completed entries without timestamps. If that's the case, please add a comment explaining the invariant (e.g., "Backend omits timestamps for deterministic/replay entries; absence of timestamps implies completion"), so future readers don't revert this as an apparent mistake.

Without that context, this change risks hiding genuinely pending nodes.

2. Retry Count Display (xyflow-nodes.tsx:278)

Before: x{data.retryCount} — After: x{data.retryCount + 1}

The badge only renders when retryCount > 0 (line 265), so retryCount = 1 now shows x2 (1 retry = 2 total attempts). This reads as "total attempts" rather than "retry count", which is clearer. The fix is correct assuming retryCount is 0-indexed for retries. Worth confirming against the backend schema — if the field is named retryCount (not attemptCount), consider adding a tooltip so the semantics are clear to users.

---

Positives

ReactFlow Interaction Model (workflow-visualizer.tsx)

Making nodes non-draggable (nodesDraggable={false}), non-connectable (nodesConnectable={false}), and edges non-reconnectable (edgesReconnectable={false}) is appropriate for a read-only visualization. Changing panOnDrag={[1, 2]} to panOnDrag combined with nodesDraggable={false} means dragging on a node pans the canvas rather than moving the node — good UX. Setting panActivationKeyCode={null} removes the key requirement for panning, making navigation more intuitive.

Import Reorganization

Grouping type imports separately and formatting the union type across multiple lines are clean style improvements.

---

Checklist

No tests were added and the PR checklist items for tests and self-review are unchecked. Given that the status fallback change affects how workflow history is rendered, a test covering the itemToNodeData function with various combinations of rawStatus, startedAt, and completedAt would help prevent regressions.

---

Verdict

The ReactFlow and retry count changes look good. The status fallback change needs either a clarifying comment explaining why entries with no timestamps should default to "completed" rather than "pending", or confirmation from the author that this is the correct semantic for all such entries.