chore(core): add x-rivet-endpoint header for serverless runners & cleanup severless runner setup

[NathanFlurry]

Depends on rivet-dev/rivet#3077

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
rivetkit-serverless	Ready	Preview	Comment	Oct 7, 2025 9:19pm

[claude]

Claude finished @NathanFlurry's task —— View job

---

Pull Request Review

I've completed a comprehensive review of this PR that adds the x-rivet-endpoint header for serverless runners and cleans up serverless runner setup. Here's my detailed feedback:

Review Checklist:

• Read and analyze all changed files
• Review code quality and best practices
• Check for potential bugs or issues
• Evaluate performance considerations
• Assess security concerns
• Analyze test coverage implications
• Provide comprehensive feedback

✅ Code Quality & Best Practices

The code follows the established patterns and conventions well:

• Proper use of Zod schemas for validation (ServerlessStartHeadersSchema)
• Consistent error handling with custom error classes
• Good separation of concerns between router logic and validation
• Follows existing TypeScript and ESLint standards

🐛 Potential Bugs & Issues

1. Redundant Token Assignment - packages/rivetkit/src/drivers/engine/actor-driver.ts:82

const token = runConfig.token ?? runConfig.token;

This line assigns runConfig.token to itself, which appears to be a copy-paste error. Should likely be:

const token = runConfig.token ?? someOtherTokenSource;

2. Missing Error Handling - packages/rivetkit/src/manager/router.ts:161-173

The serverless start endpoint parses headers but only throws InvalidRequest for validation errors. Consider adding more specific error handling for individual header validation failures to improve debugging.

3. Potential Race Condition - packages/rivetkit/src/drivers/engine/actor-driver.ts:178-182

The actor driver cleanup in tests could benefit from proper synchronization to ensure actors are fully stopped before cleanup completes.

🚀 Performance Considerations

Positive Changes:

• Reduced object creation: The router schema extraction into a separate file reduces duplication
• Efficient header parsing: Direct header access without unnecessary processing
• Streamlined serverless setup: Removed redundant configuration steps

Areas for Improvement:

• Consider caching parsed headers in the serverless start endpoint if this route is called frequently
• The Object.assign({}, runConfig) in router.ts:188 could be replaced with structured cloning for better performance

🔒 Security Concerns

1. Header Validation - Good Security Practice ✅

The new ServerlessStartHeadersSchema properly validates all required headers and includes appropriate type coercion for numeric values.

2. Token Handling - Secure ✅

Token handling remains secure with optional tokens and proper header-based authentication.

3. Input Sanitization - Could Be Improved ⚠️

Consider adding length limits to string headers to prevent potential DoS attacks through extremely long header values.

🧪 Test Coverage

Current State:

• The driver test suite has been updated to handle the new serverless configuration
• Engine driver tests properly skip inline client testing (appropriate for remote driver)

Recommendations:

1. Add unit tests for the new ServerlessStartHeadersSchema validation
2. Add integration tests for the serverless start endpoint with various header combinations
3. Test error scenarios like missing required headers, invalid numeric values, etc.

📝 Specific Code Improvements

1. Type Safety Enhancement - packages/rivetkit/src/manager/router.ts:174-175

// Current
const { endpoint, token, totalSlots, runnerName, namespace } = parseResult.data;

// Suggested: Add explicit typing for better IDE support
const { endpoint, token, totalSlots, runnerName, namespace }: ServerlessStartHeaders = parseResult.data;

2. Error Message Improvement - packages/rivetkit/src/manager/router.ts:169-172

Consider providing more detailed error messages:

if (!parseResult.success) {
    const firstError = parseResult.error.issues[0];
    throw new InvalidRequest(
        `Invalid serverless start headers: ${firstError?.path.join('.')} - ${firstError?.message}` ??
        "invalid serverless start headers"
    );
}

3. Configuration Validation - packages/rivetkit/src/registry/mod.ts:58-62

Good validation logic for autoConfigureServerless usage restrictions.

🎯 Overall Assessment

This is a solid PR that successfully implements the required functionality with good attention to:

• ✅ Proper header validation and parsing
• ✅ Clean separation of concerns
• ✅ Backward compatibility
• ✅ Consistent error handling patterns

The main issues are minor (the token assignment bug) and the code quality is high overall. The serverless runner setup cleanup is well-executed and removes unnecessary complexity.

Recommendation: ✅ Approve with minor fixes - Address the token assignment issue and consider the suggested improvements for enhanced robustness.

[NathanFlurry]

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

• chore(core): handle errors inside message handlers #1364
• chore(core): add smoke test #1363
• chore: fix serverless config #1361
• chore(core): add x-rivet-endpoint header for serverless runners & cleanup severless runner setup #1359 👈 (View in Graphite)
• fix(next): fix local dev #1352
• chore(core): add support for auto-configuring serverless #1356 : 1 other dependent PR (#1357 )
• chore(core): add build:fast script #1355
• feat(core): support running engine #1353
• fix(example-deno): fix check-types #1351
• chore(core): simplify config #1350
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• merge queue - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

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

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

@rivetkit/actor

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

@rivetkit/cloudflare-workers

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

@rivetkit/core

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

@rivetkit/db

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

@rivetkit/framework-base

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

@rivetkit/next-js

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

@rivetkit/react

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

rivetkit

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

@rivetkit/sql-loader

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

commit: a022c4f

[claude]

Claude finished @NathanFlurry's task —— View job

---

Pull Request Review

I've completed a comprehensive review of this PR that adds the x-rivet-endpoint header for serverless runners and cleans up serverless runner setup. Here's my detailed feedback:

Review Checklist:

• Read and analyze all changed files
• Review code quality and best practices
• Check for potential bugs or issues
• Evaluate performance considerations
• Assess security concerns
• Analyze test coverage implications
• Provide comprehensive feedback

✅ Code Quality & Best Practices

The code follows the established patterns and conventions well:

• Proper use of Zod schemas for validation (ServerlessStartHeadersSchema)
• Consistent error handling with custom error classes
• Good separation of concerns between router logic and validation
• Follows existing TypeScript and ESLint standards

🐛 Potential Bugs & Issues

1. Redundant Token Assignment - packages/rivetkit/src/drivers/engine/actor-driver.ts:82

const token = runConfig.token ?? runConfig.token;

This line assigns runConfig.token to itself, which appears to be a copy-paste error. Should likely be:

const token = runConfig.token ?? someOtherTokenSource;

2. Missing Error Handling - packages/rivetkit/src/manager/router.ts:161-173

The serverless start endpoint parses headers but only throws InvalidRequest for validation errors. Consider adding more specific error handling for individual header validation failures to improve debugging.

3. Potential Race Condition - packages/rivetkit/src/drivers/engine/actor-driver.ts:178-182

The actor driver cleanup in tests could benefit from proper synchronization to ensure actors are fully stopped before cleanup completes.

🚀 Performance Considerations

Positive Changes:

• Reduced object creation: The router schema extraction into a separate file reduces duplication
• Efficient header parsing: Direct header access without unnecessary processing
• Streamlined serverless setup: Removed redundant configuration steps

Areas for Improvement:

• Consider caching parsed headers in the serverless start endpoint if this route is called frequently
• The Object.assign({}, runConfig) in router.ts:188 could be replaced with structured cloning for better performance

🔒 Security Concerns

1. Header Validation - Good Security Practice ✅

The new ServerlessStartHeadersSchema properly validates all required headers and includes appropriate type coercion for numeric values.

2. Token Handling - Secure ✅

Token handling remains secure with optional tokens and proper header-based authentication.

3. Input Sanitization - Could Be Improved ⚠️

Consider adding length limits to string headers to prevent potential DoS attacks through extremely long header values.

🧪 Test Coverage

Current State:

• The driver test suite has been updated to handle the new serverless configuration
• Engine driver tests properly skip inline client testing (appropriate for remote driver)

Recommendations:

1. Add unit tests for the new ServerlessStartHeadersSchema validation
2. Add integration tests for the serverless start endpoint with various header combinations
3. Test error scenarios like missing required headers, invalid numeric values, etc.

📝 Specific Code Improvements

1. Type Safety Enhancement - packages/rivetkit/src/manager/router.ts:174-175

// Current
const { endpoint, token, totalSlots, runnerName, namespace } = parseResult.data;

// Suggested: Add explicit typing for better IDE support
const { endpoint, token, totalSlots, runnerName, namespace }: ServerlessStartHeaders = parseResult.data;

2. Error Message Improvement - packages/rivetkit/src/manager/router.ts:169-172

Consider providing more detailed error messages:

if (!parseResult.success) {
    const firstError = parseResult.error.issues[0];
    throw new InvalidRequest(
        `Invalid serverless start headers: ${firstError?.path.join('.')} - ${firstError?.message}` ??
        "invalid serverless start headers"
    );
}

3. Configuration Validation - packages/rivetkit/src/registry/mod.ts:58-62

Good validation logic for autoConfigureServerless usage restrictions.

🎯 Overall Assessment

This is a solid PR that successfully implements the required functionality with good attention to:

• ✅ Proper header validation and parsing
• ✅ Clean separation of concerns
• ✅ Backward compatibility
• ✅ Consistent error handling patterns

The main issues are minor (the token assignment bug) and the code quality is high overall. The serverless runner setup cleanup is well-executed and removes unnecessary complexity.

Recommendation: ✅ Approve with minor fixes - Address the token assignment issue and consider the suggested improvements for enhanced robustness.

[claude]

Claude finished @NathanFlurry's task —— View job

---

Pull Request Review

I've completed a comprehensive review of this PR that adds the x-rivet-endpoint header for serverless runners and cleans up serverless runner setup. Here's my detailed feedback:

Review Checklist:

• Read and analyze all changed files
• Review code quality and best practices
• Check for potential bugs or issues
• Evaluate performance considerations
• Assess security concerns
• Analyze test coverage implications
• Provide comprehensive feedback

✅ Code Quality & Best Practices

The code follows the established patterns and conventions well:

• Proper use of Zod schemas for validation (ServerlessStartHeadersSchema)
• Consistent error handling with custom error classes
• Good separation of concerns between router logic and validation
• Follows existing TypeScript and ESLint standards

🐛 Potential Bugs & Issues

1. Redundant Token Assignment - packages/rivetkit/src/drivers/engine/actor-driver.ts:82

const token = runConfig.token ?? runConfig.token;

This line assigns runConfig.token to itself, which appears to be a copy-paste error. Should likely be:

const token = runConfig.token ?? someOtherTokenSource;

2. Missing Error Handling - packages/rivetkit/src/manager/router.ts:161-173

The serverless start endpoint parses headers but only throws InvalidRequest for validation errors. Consider adding more specific error handling for individual header validation failures to improve debugging.

3. Potential Race Condition - packages/rivetkit/src/drivers/engine/actor-driver.ts:178-182

The actor driver cleanup in tests could benefit from proper synchronization to ensure actors are fully stopped before cleanup completes.

🚀 Performance Considerations

Positive Changes:

• Reduced object creation: The router schema extraction into a separate file reduces duplication
• Efficient header parsing: Direct header access without unnecessary processing
• Streamlined serverless setup: Removed redundant configuration steps

Areas for Improvement:

• Consider caching parsed headers in the serverless start endpoint if this route is called frequently
• The Object.assign({}, runConfig) in router.ts:188 could be replaced with structured cloning for better performance

🔒 Security Concerns

1. Header Validation - Good Security Practice ✅

The new ServerlessStartHeadersSchema properly validates all required headers and includes appropriate type coercion for numeric values.

2. Token Handling - Secure ✅

Token handling remains secure with optional tokens and proper header-based authentication.

3. Input Sanitization - Could Be Improved ⚠️

Consider adding length limits to string headers to prevent potential DoS attacks through extremely long header values.

🧪 Test Coverage

Current State:

• The driver test suite has been updated to handle the new serverless configuration
• Engine driver tests properly skip inline client testing (appropriate for remote driver)

Recommendations:

1. Add unit tests for the new ServerlessStartHeadersSchema validation
2. Add integration tests for the serverless start endpoint with various header combinations
3. Test error scenarios like missing required headers, invalid numeric values, etc.

📝 Specific Code Improvements

1. Type Safety Enhancement - packages/rivetkit/src/manager/router.ts:174-175

// Current
const { endpoint, token, totalSlots, runnerName, namespace } = parseResult.data;

// Suggested: Add explicit typing for better IDE support
const { endpoint, token, totalSlots, runnerName, namespace }: ServerlessStartHeaders = parseResult.data;

2. Error Message Improvement - packages/rivetkit/src/manager/router.ts:169-172

Consider providing more detailed error messages:

if (!parseResult.success) {
    const firstError = parseResult.error.issues[0];
    throw new InvalidRequest(
        `Invalid serverless start headers: ${firstError?.path.join('.')} - ${firstError?.message}` ??
        "invalid serverless start headers"
    );
}

3. Configuration Validation - packages/rivetkit/src/registry/mod.ts:58-62

Good validation logic for autoConfigureServerless usage restrictions.

🎯 Overall Assessment

This is a solid PR that successfully implements the required functionality with good attention to:

• ✅ Proper header validation and parsing
• ✅ Clean separation of concerns
• ✅ Backward compatibility
• ✅ Consistent error handling patterns

The main issues are minor (the token assignment bug) and the code quality is high overall. The serverless runner setup cleanup is well-executed and removes unnecessary complexity.

Recommendation: ✅ Approve with minor fixes - Address the token assignment issue and consider the suggested improvements for enhanced robustness.

---

[claude]

Claude finished @NathanFlurry's task —— View job

---

Pull Request Review

I've completed a comprehensive review of this PR that adds the x-rivet-endpoint header for serverless runners and cleans up serverless runner setup. Here's my detailed feedback:

Review Checklist:

• Read and analyze all changed files
• Review code quality and best practices
• Check for potential bugs or issues
• Evaluate performance considerations
• Assess security concerns
• Analyze test coverage implications
• Provide comprehensive feedback

✅ Code Quality & Best Practices

The code follows the established patterns and conventions well:

• Proper use of Zod schemas for validation (ServerlessStartHeadersSchema)
• Consistent error handling with custom error classes
• Good separation of concerns between router logic and validation
• Follows existing TypeScript and ESLint standards

🐛 Potential Bugs & Issues

1. Redundant Token Assignment - packages/rivetkit/src/drivers/engine/actor-driver.ts:82

const token = runConfig.token ?? runConfig.token;

This line assigns runConfig.token to itself, which appears to be a copy-paste error. Should likely be:

const token = runConfig.token ?? someOtherTokenSource;

2. Missing Error Handling - packages/rivetkit/src/manager/router.ts:161-173

The serverless start endpoint parses headers but only throws InvalidRequest for validation errors. Consider adding more specific error handling for individual header validation failures to improve debugging.

3. Potential Race Condition - packages/rivetkit/src/drivers/engine/actor-driver.ts:178-182

The actor driver cleanup in tests could benefit from proper synchronization to ensure actors are fully stopped before cleanup completes.

🚀 Performance Considerations

Positive Changes:

• Reduced object creation: The router schema extraction into a separate file reduces duplication
• Efficient header parsing: Direct header access without unnecessary processing
• Streamlined serverless setup: Removed redundant configuration steps

Areas for Improvement:

• Consider caching parsed headers in the serverless start endpoint if this route is called frequently
• The Object.assign({}, runConfig) in router.ts:188 could be replaced with structured cloning for better performance

🔒 Security Concerns

1. Header Validation - Good Security Practice ✅

The new ServerlessStartHeadersSchema properly validates all required headers and includes appropriate type coercion for numeric values.

2. Token Handling - Secure ✅

Token handling remains secure with optional tokens and proper header-based authentication.

3. Input Sanitization - Could Be Improved ⚠️

Consider adding length limits to string headers to prevent potential DoS attacks through extremely long header values.

🧪 Test Coverage

Current State:

• The driver test suite has been updated to handle the new serverless configuration
• Engine driver tests properly skip inline client testing (appropriate for remote driver)

Recommendations:

1. Add unit tests for the new ServerlessStartHeadersSchema validation
2. Add integration tests for the serverless start endpoint with various header combinations
3. Test error scenarios like missing required headers, invalid numeric values, etc.

📝 Specific Code Improvements

1. Type Safety Enhancement - packages/rivetkit/src/manager/router.ts:174-175

// Current
const { endpoint, token, totalSlots, runnerName, namespace } = parseResult.data;

// Suggested: Add explicit typing for better IDE support
const { endpoint, token, totalSlots, runnerName, namespace }: ServerlessStartHeaders = parseResult.data;

2. Error Message Improvement - packages/rivetkit/src/manager/router.ts:169-172

Consider providing more detailed error messages:

if (!parseResult.success) {
    const firstError = parseResult.error.issues[0];
    throw new InvalidRequest(
        `Invalid serverless start headers: ${firstError?.path.join('.')} - ${firstError?.message}` ??
        "invalid serverless start headers"
    );
}

3. Configuration Validation - packages/rivetkit/src/registry/mod.ts:58-62

Good validation logic for autoConfigureServerless usage restrictions.

🎯 Overall Assessment

This is a solid PR that successfully implements the required functionality with good attention to:

• ✅ Proper header validation and parsing
• ✅ Clean separation of concerns
• ✅ Backward compatibility
• ✅ Consistent error handling patterns

The main issues are minor (the token assignment bug) and the code quality is high overall. The serverless runner setup cleanup is well-executed and removes unnecessary complexity.

Recommendation: ✅ Approve with minor fixes - Address the token assignment issue and consider the suggested improvements for enhanced robustness.

---

[graphite-app]

There appears to be a redundant self-reference in this line. The expression runConfig.token ?? runConfig.token will always evaluate to runConfig.token since the nullish coalescing operator (??) only uses the right-hand value when the left-hand value is null or undefined.

Since the config parameter was removed from this function, this should be simplified to:

const token = runConfig.token;

Suggested change

	const token = runConfig.token ?? runConfig.token;
	const token = runConfig.token;

Spotted by Diamond



Is this helpful? React 👍 or 👎 to let us know.

[graphite-app]

Merge activity

• Oct 7, 11:36 PM UTC: NathanFlurry added this pull request to the Graphite merge queue.
• Oct 7, 11:36 PM UTC: CI is running for this pull request on a draft pull request (#1365) due to your merge queue CI optimization settings.
• Oct 7, 11:37 PM UTC: Merged by the Graphite merge queue via draft PR: #1365.