refactor(frontend): support envoys

[jog1t]

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-4651 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
frontend-cloud	😴 Sleeping (View Logs)	Web	Apr 21, 2026 at 12:43 am
frontend-inspector	😴 Sleeping (View Logs)	Web	Apr 21, 2026 at 12:39 am
website	😴 Sleeping (View Logs)	Web	Apr 17, 2026 at 1:15 pm
kitchen-sink	❌ Build Failed (View Logs)	Web	Apr 16, 2026 at 9:42 pm
mcp-hub	✅ Success (View Logs)	Web	Apr 14, 2026 at 5:46 pm
ladle	❌ Build Failed (View Logs)	Web	Apr 14, 2026 at 5:46 pm

[jog1t]

• refactor: inspector tabs bundled with actor #4670
• refactor(rivetkit): move devtools to local script #4669
• fix(rivetkit): minor rivetkit debug changes #4676
• feat(frontend): add enoys to the runner table #4675
• refactor(frontend): support envoys #4651 👈 (View in Graphite)
• main

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

[claude]

PR Review: refactor(frontend): support envoys (#4651)

Summary

This PR refactors the frontend to support the new envoy runner protocol. Core changes:

1. Protocol detection: protocolVersion field on RunnerConfigResponse discriminates legacy (runner pool) vs new (envoy) configs.
2. Field deprecations: maxRunners, minRunners, slotsPerRunner, runnersMargin replaced by drainGracePeriod and maxConcurrentActors.
3. Sleep/Reschedule UI: New ActorSleepButton and ActorRescheduleButton, gated by canSleepActors/canRescheduleActors feature flags.
4. Crash policy removed: All actor creates now hardcode crashPolicy: 'destroy'.
5. SDK updates: TypeScript, Go, and Rust SDK types updated.

---

Code Quality

1. Inverted isNew during fresh onboarding (potential bug)

In connect-manual-serverless-frame.tsx:

const isNew = (existing[dc] as any)?.protocolVersion != null;

During initial onboarding existing[dc] is undefined, so isNew is always false. Fresh installs will always generate legacy-format configs instead of the new envoy format. The fallback should default to true when no existing config is present.

2. Unnecessary as any casts

In connect-manual-serverless-frame.tsx, existing is typed as Record<string, Rivet.RunnerConfig> but protocolVersion only exists on RunnerConfigResponse. Update the type instead of casting with as any. In edit-runner-config.tsx, maxConcurrentActors is already defined on Rivet.RunnerConfigServerless, so those casts are also unnecessary.

3. Deprecated fields sent as 0 instead of omitted

In the new-protocol path both maxRunners: 0 and slotsPerRunner: 0 are sent explicitly. These deprecated fields should be omitted entirely (or set to undefined) to avoid backend confusion if 0 is treated differently from absent.

4. Duplicated isNew branching

The old/new protocol branch appears in at least four places: connect-manual-serverless-frame.tsx, SharedSettingsForm, DatacenterSettingsForm, and DatacenterAccordion. Extract a shared buildServerlessConfig(values, isNew) helper to reduce repetition and keep the logic consistent.

5. hasProtocolVersion is all-or-nothing for mixed configs

hasProtocolVersion returns true if any datacenter has a protocol version, then drives field visibility for all datacenters. In mixed legacy/envoy environments this will show wrong fields for some DCs. dcHasProtocolVersion is the correct per-DC check and is already used in DatacenterAccordion — the shared form should use it consistently.

6. Silent crash policy behavior change

crashPolicy was previously user-selectable (defaulting to sleep). It is now silently hardcoded to destroy with no comment or migration note. Existing actors relying on the sleep crash policy will behave differently after upgrade. This should be noted in a code comment at the hardcoded value in engine-data-provider.tsx.

7. Missing per-datacenter defaults for new fields

In DatacenterSettingsForm, the defaultValues map does not populate drainGracePeriod or maxConcurrentActors for new-protocol DCs, so those fields will be empty/undefined on first open.

---

Performance

8. Predicate-based query invalidation

The sleep/reschedule mutations in default-data-provider.tsx use predicate scanning across all cached queries. A direct key-based invalidateQueries on the specific actor query key would be more efficient.

---

Security

No issues. The new actorsSleep/actorsReschedule endpoints are standard authenticated calls. Feature-flagging them to false in non-engine contexts is appropriate.

---

Test Coverage

No tests added (acceptable for a draft). Before merge, add tests for the buildServerlessConfig branching logic and the isNew detection path — especially the fresh-onboarding case where existing[dc] is undefined.

---

Items to Address Before Merge

Priority	Issue
High	Inverted isNew for fresh onboarding — new installs always get legacy format
High	hasProtocolVersion drives all-DC form fields from a single DC's state
Medium	Deprecated maxRunners: 0, slotsPerRunner: 0 should be omitted, not zeroed
Medium	Missing drainGracePeriod/maxConcurrentActors defaults in per-datacenter form
Low	Unnecessary as any casts hiding type mismatches
Low	Undocumented crashPolicy behavior change (sleep → destroy)

[github-actions]

Preview packages published to npm

Install with:

npm install rivetkit@pr-4651

All packages published as 0.0.0-pr.4651.703fb05 with tag pr-4651.

Engine binary is shipped via @rivetkit/engine-cli on linux-x64-musl, linux-arm64-musl, darwin-x64, and darwin-arm64. Windows users should use the release installer or set RIVET_ENGINE_BINARY.

Docker images:

docker pull rivetdev/engine:slim-703fb05
docker pull rivetdev/engine:full-703fb05

Individual packages

npm install rivetkit@pr-4651
npm install @rivetkit/react@pr-4651
npm install @rivetkit/rivetkit-native@pr-4651
npm install @rivetkit/sqlite-wasm@pr-4651
npm install @rivetkit/workflow-engine@pr-4651