chore(core): add support for auto-configuring serverless

[NathanFlurry]

No description provided.

[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 5, 2025 10:04pm

[claude]

Claude finished @NathanFlurry's task —— View job

---

PR Review: Auto-configuring Serverless Support

I've completed my review of this PR which adds auto-configuration support for serverless deployments. Here's my comprehensive feedback:

Todo List:

• Read repository guidelines and setup instructions
• Analyze new serverless example structure
• Review core registry modifications
• Review router changes
• Check test coverage and quality
• Identify potential issues and improvements
• Provide comprehensive feedback

---

✅ Positive Aspects

1. Well-structured example: The counter-serverless example follows repository conventions exactly as specified in CLAUDE.md
2. Clear separation of concerns: Router logic cleanly separated between serverless and manager routes
3. Comprehensive configuration: The autoConfigureServerless option supports both boolean and detailed object configuration
4. Good test coverage: The example includes proper test using vitest and the testing framework
5. Proper error handling: Configuration function includes try-catch and descriptive error messages

🔧 Code Quality & Best Practices

Good:

• Follows established naming conventions (camelCase for variables, PascalCase for types)
• Uses structured logging consistently with logger().info/debug/error
• Proper use of Zod schemas for validation
• Type-safe implementation throughout

Areas for improvement:

• Consider extracting magic numbers to constants (e.g., 15 * 60_000 → DEFAULT_REQUEST_LIFESPAN)

🐛 Potential Issues

1. Security Concerns

• High Priority: The configureServerlessRunner function uses fetch() with user-provided tokens and endpoints without URL validation (packages/rivetkit/src/registry/mod.ts:272-287)
• Recommendation: Add URL validation to ensure config.endpoint is a valid HTTP/HTTPS URL and consider input sanitization

2. Error Handling

• Medium Priority: In configureServerlessRunner, if the fetch request fails, the error is logged and re-thrown, but the application continues running (packages/rivetkit/src/registry/mod.ts:301-307)
• Recommendation: Consider whether silent failures are appropriate or if the app should fail fast

3. Race Conditions

• Low Priority: The Promise.all(readyPromises) pattern could lead to race conditions if multiple async operations access shared state
• Current implementation seems safe as operations are mostly independent

🚀 Performance Considerations

1. Good: Lazy loading of serverless configuration prevents unnecessary overhead for non-serverless deployments
2. Good: Router efficiently routes between serverless and manager modes using conditional logic
3. Minor: The serverlessActorDriverBuilder function creates a new driver on each call - consider caching if performance becomes an issue

🧪 Test Coverage

Strengths:

• Basic functionality well tested in counter.test.ts
• Tests cover increment actions and event emission
• Uses proper testing patterns with setupTest

Gaps:

• Missing: Tests for serverless auto-configuration functionality
• Missing: Error case testing (invalid tokens, network failures)
• Missing: Integration tests for the /start endpoint

🔐 Security Analysis

Critical Issues:

1. Unvalidated URL construction in configureServerlessRunner:

   const configUrl = `${config.endpoint}/runner-configs/${config.runnerName}?namespace=${config.namespace}`;

   • No validation that config.endpoint is a safe URL
   • Potential for URL injection if runnerName or namespace contain special characters

Recommendations:

1. Add URL validation:

   // Validate endpoint URL
   try {
     new URL(config.endpoint);
   } catch {
     throw new Error('Invalid endpoint URL');
   }
   
   // Encode URL components
   const configUrl = `${config.endpoint}/runner-configs/${encodeURIComponent(config.runnerName)}?namespace=${encodeURIComponent(config.namespace)}`;

📝 Minor Improvements

1. packages/rivetkit/src/registry/mod.ts:262: Extract magic numbers to named constants
2. packages/rivetkit/src/registry/run-config.ts:120: Consider adding JSDoc for the complex autoConfigureServerless union type
3. examples/counter-serverless/README.md: Could include more specific instructions about setting up RIVET_TOKEN

🎯 Overall Assessment

This is a solid implementation that properly implements the serverless auto-configuration feature. The code follows project conventions well and provides good functionality. The main concerns are around security validation and test coverage for the new serverless-specific features.

Priority for fixes:

1. High: Add URL validation and input sanitization for security
2. Medium: Add tests for serverless configuration functionality
3. Low: Extract magic numbers to constants

The PR is ready for merge after addressing the security concerns around URL validation.

---

[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): add support for auto-configuring serverless #1356 : 2 dependent PRs (#1352 , #1357 ) 👈 (View in Graphite)
• 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@1356

@rivetkit/cloudflare-workers

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

@rivetkit/core

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

@rivetkit/db

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

@rivetkit/framework-base

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

@rivetkit/next-js

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

@rivetkit/react

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

rivetkit

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

@rivetkit/sql-loader

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

commit: 1276192

[claude]

Claude finished @NathanFlurry's task —— View job

---

PR Review: Auto-configuring Serverless Support

I've completed my review of this PR which adds auto-configuration support for serverless deployments. Here's my comprehensive feedback:

Todo List:

• Read repository guidelines and setup instructions
• Analyze new serverless example structure
• Review core registry modifications
• Review router changes
• Check test coverage and quality
• Identify potential issues and improvements
• Provide comprehensive feedback

---

✅ Positive Aspects

1. Well-structured example: The counter-serverless example follows repository conventions exactly as specified in CLAUDE.md
2. Clear separation of concerns: Router logic cleanly separated between serverless and manager routes
3. Comprehensive configuration: The autoConfigureServerless option supports both boolean and detailed object configuration
4. Good test coverage: The example includes proper test using vitest and the testing framework
5. Proper error handling: Configuration function includes try-catch and descriptive error messages

🔧 Code Quality & Best Practices

Good:

• Follows established naming conventions (camelCase for variables, PascalCase for types)
• Uses structured logging consistently with logger().info/debug/error
• Proper use of Zod schemas for validation
• Type-safe implementation throughout

Areas for improvement:

• Consider extracting magic numbers to constants (e.g., 15 * 60_000 → DEFAULT_REQUEST_LIFESPAN)

🐛 Potential Issues

1. Security Concerns

• High Priority: The configureServerlessRunner function uses fetch() with user-provided tokens and endpoints without URL validation (packages/rivetkit/src/registry/mod.ts:272-287)
• Recommendation: Add URL validation to ensure config.endpoint is a valid HTTP/HTTPS URL and consider input sanitization

2. Error Handling

• Medium Priority: In configureServerlessRunner, if the fetch request fails, the error is logged and re-thrown, but the application continues running (packages/rivetkit/src/registry/mod.ts:301-307)
• Recommendation: Consider whether silent failures are appropriate or if the app should fail fast

3. Race Conditions

• Low Priority: The Promise.all(readyPromises) pattern could lead to race conditions if multiple async operations access shared state
• Current implementation seems safe as operations are mostly independent

🚀 Performance Considerations

1. Good: Lazy loading of serverless configuration prevents unnecessary overhead for non-serverless deployments
2. Good: Router efficiently routes between serverless and manager modes using conditional logic
3. Minor: The serverlessActorDriverBuilder function creates a new driver on each call - consider caching if performance becomes an issue

🧪 Test Coverage

Strengths:

• Basic functionality well tested in counter.test.ts
• Tests cover increment actions and event emission
• Uses proper testing patterns with setupTest

Gaps:

• Missing: Tests for serverless auto-configuration functionality
• Missing: Error case testing (invalid tokens, network failures)
• Missing: Integration tests for the /start endpoint

🔐 Security Analysis

Critical Issues:

1. Unvalidated URL construction in configureServerlessRunner:

   const configUrl = `${config.endpoint}/runner-configs/${config.runnerName}?namespace=${config.namespace}`;

   • No validation that config.endpoint is a safe URL
   • Potential for URL injection if runnerName or namespace contain special characters

Recommendations:

1. Add URL validation:

   // Validate endpoint URL
   try {
     new URL(config.endpoint);
   } catch {
     throw new Error('Invalid endpoint URL');
   }
   
   // Encode URL components
   const configUrl = `${config.endpoint}/runner-configs/${encodeURIComponent(config.runnerName)}?namespace=${encodeURIComponent(config.namespace)}`;

📝 Minor Improvements

1. packages/rivetkit/src/registry/mod.ts:262: Extract magic numbers to named constants
2. packages/rivetkit/src/registry/run-config.ts:120: Consider adding JSDoc for the complex autoConfigureServerless union type
3. examples/counter-serverless/README.md: Could include more specific instructions about setting up RIVET_TOKEN

🎯 Overall Assessment

This is a solid implementation that properly implements the serverless auto-configuration feature. The code follows project conventions well and provides good functionality. The main concerns are around security validation and test coverage for the new serverless-specific features.

Priority for fixes:

1. High: Add URL validation and input sanitization for security
2. Medium: Add tests for serverless configuration functionality
3. Low: Extract magic numbers to constants

The PR is ready for merge after addressing the security concerns around URL validation.

---

[claude]

Claude finished @NathanFlurry's task —— View job

---

Reviewing PR: Auto-configuring Serverless Support

Todo List:

• Read repository guidelines and setup instructions
• Analyze new serverless example structure
• Review core registry modifications
• Review router changes
• Check test coverage and quality
• Identify potential issues and improvements
• Provide comprehensive feedback

---

✅ Positive Aspects

1. Well-structured example: The counter-serverless example follows repository conventions exactly as specified in CLAUDE.md
2. Clear separation of concerns: Router logic cleanly separated between serverless and manager routes
3. Comprehensive configuration: The autoConfigureServerless option supports both boolean and detailed object configuration
4. Good test coverage: The example includes proper test using vitest and the testing framework
5. Proper error handling: Configuration function includes try-catch and descriptive error messages

🔧 Code Quality & Best Practices

Good:

• Follows established naming conventions (camelCase for variables, PascalCase for types)
• Uses structured logging consistently with logger().info/debug/error
• Proper use of Zod schemas for validation
• Type-safe implementation throughout

Areas for improvement:

• Consider extracting magic numbers to constants (e.g., 15 * 60_000 → DEFAULT_REQUEST_LIFESPAN)

🐛 Potential Issues

1. Security Concerns

• High Priority: The configureServerlessRunner function uses fetch() with user-provided tokens and endpoints without URL validation (packages/rivetkit/src/registry/mod.ts:272-287)
• Recommendation: Add URL validation to ensure config.endpoint is a valid HTTP/HTTPS URL and consider input sanitization

2. Error Handling

• Medium Priority: In configureServerlessRunner, if the fetch request fails, the error is logged and re-thrown, but the application continues running (packages/rivetkit/src/registry/mod.ts:301-307)
• Recommendation: Consider whether silent failures are appropriate or if the app should fail fast

3. Race Conditions

• Low Priority: The Promise.all(readyPromises) pattern could lead to race conditions if multiple async operations access shared state
• Current implementation seems safe as operations are mostly independent

🚀 Performance Considerations

1. Good: Lazy loading of serverless configuration prevents unnecessary overhead for non-serverless deployments
2. Good: Router efficiently routes between serverless and manager modes using conditional logic
3. Minor: The serverlessActorDriverBuilder function creates a new driver on each call - consider caching if performance becomes an issue

🧪 Test Coverage

Strengths:

• Basic functionality well tested in counter.test.ts
• Tests cover increment actions and event emission
• Uses proper testing patterns with setupTest

Gaps:

• Missing: Tests for serverless auto-configuration functionality
• Missing: Error case testing (invalid tokens, network failures)
• Missing: Integration tests for the /start endpoint

🔐 Security Analysis

Critical Issues:

1. Unvalidated URL construction in configureServerlessRunner:

   const configUrl = `${config.endpoint}/runner-configs/${config.runnerName}?namespace=${config.namespace}`;

   • No validation that config.endpoint is a safe URL
   • Potential for URL injection if runnerName or namespace contain special characters

Recommendations:

1. Add URL validation:

   // Validate endpoint URL
   try {
     new URL(config.endpoint);
   } catch {
     throw new Error('Invalid endpoint URL');
   }
   
   // Encode URL components
   const configUrl = `${config.endpoint}/runner-configs/${encodeURIComponent(config.runnerName)}?namespace=${encodeURIComponent(config.namespace)}`;

📝 Minor Improvements

1. packages/rivetkit/src/registry/mod.ts:262: Extract magic numbers to named constants
2. packages/rivetkit/src/registry/run-config.ts:120: Consider adding JSDoc for the complex autoConfigureServerless union type
3. examples/counter-serverless/README.md: Could include more specific instructions about setting up RIVET_TOKEN

🎯 Overall Assessment

This is a solid implementation that properly implements the serverless auto-configuration feature. The code follows project conventions well and provides good functionality. The main concerns are around security validation and test coverage for the new serverless-specific features.

Priority for fixes:

1. High: Add URL validation and input sanitization for security
2. Medium: Add tests for serverless configuration functionality
3. Low: Extract magic numbers to constants

The PR is ready for merge after addressing the security concerns around URL validation.

---

[graphite-app]

Merge activity

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