feat: serverless

[MasterPtato]

Fixes KIT-288

[vercel]

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

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

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage
• Provide comprehensive feedback

Code Quality & Best Practices ✅

Positive aspects:

• Code follows established TypeScript conventions with proper typing
• Good use of structured logging with logger() calls
• Proper error handling with custom error classes extending ActorError
• Consistent naming conventions (camelCase for variables/functions)
• Good separation of concerns between different modules

Areas for improvement:

• Some TODOs remain in comments (e.g., packages/rivetkit/src/manager/router.ts:289-290)
• Missing JSDoc documentation for public APIs

Potential Bugs & Issues 🔍

High Priority:

1. packages/rivetkit/src/manager/router.ts:289-290 - Empty name field in getForId call:

   name: "", // TODO: The API doesn't provide the name, this may need to be resolved

   This could cause issues with actor lookup validation.

2. packages/next-js/src/mod.ts:12-13 - Async params destructuring:

   const fetchWrapper = async (request: Request, { params }: { params: Promise<{ all: string[] }> }) => {
     const { all } = await params;

   This pattern suggests compatibility with Next.js 15's async params, but should be verified for backward compatibility.

Medium Priority:
3. packages/rivetkit/src/manager/router.ts:135-136 - JSON parsing without error handling:

connParams ? JSON.parse(connParams) : undefined,
authData ? JSON.parse(authData) : undefined,

Should wrap in try-catch blocks to handle malformed JSON.

4. packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:28-29 - Memory buffering warning:

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This could cause memory issues with large request bodies in serverless environments.

Performance Considerations ⚡

Concerns:

1. Memory buffering (actor-http-client.ts:29) - Full request buffering could be problematic in memory-constrained serverless environments
2. Synchronous JSON parsing - Multiple instances of JSON.parse() without async handling could block the event loop
3. WebSocket connection management - Complex proxy setup might have latency implications

Recommendations:

• Implement streaming request bodies for serverless compatibility
• Consider implementing request size limits
• Add connection pooling for HTTP requests where applicable

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing - Multiple locations parse JSON headers without validation (router.ts:135-136)
2. Header injection potential - Headers are copied wholesale in buildGuardHeadersForHttp() without sanitization
3. WebSocket proxy security - Complex proxy logic could have security implications if not properly validated

Recommendations:

• Validate and sanitize all user-provided headers
• Implement size limits on request bodies and headers
• Add input validation for JSON parsing operations

Test Coverage 📊

Observation: Cannot assess test coverage without running the test suite, but the presence of test infrastructure in the router suggests testing is considered.

Recommendations:

• Ensure new serverless functionality has corresponding tests
• Test error scenarios (malformed JSON, oversized requests)
• Test WebSocket proxy functionality under various network conditions

Specific Technical Feedback

packages/next-js/src/mod.ts:

• The disableServer: true flag correctly prevents duplicate server startup
• URL reconstruction logic looks correct for serverless routing
• Consider adding validation for the all parameter array

packages/rivetkit/src/common/versioned-data.ts:

• Solid implementation of data versioning with proper migration support
• Good error handling for version mismatches
• Consider adding version validation bounds

scripts/nuke-cache.sh:

• Comprehensive cache clearing script
• Good safety checks with directory existence validation
• Consider adding dry-run mode for safety

Summary

This is a well-structured serverless implementation that follows the project's coding standards. The main concerns are around error handling for JSON parsing, memory management for request buffering, and some incomplete TODOs. The architecture appears sound for serverless deployment.

Recommended actions before merge:

1. Fix the empty name field in router.ts:290
2. Add try-catch blocks around JSON.parse() calls
3. Address the memory buffering TODO or add size limits
4. Complete remaining TODOs or create issues for them

---

[MasterPtato]

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: serverless #1288 👈 (View in Graphite)
• 09-16-fix_next-js_fix_example_for_next-js #1250
• chore(core): fix missing transport for inline tests #1287 : 1 other dependent PR (#1289 )
• chore(core): fix test for sending message to specific connection sse race condition #1286
• fix(cloudflare-workers): fix alarms #1285
• chore(core): fix broadcast race condition #1284
• chore: list sideEffects #1283
• chore(core): fix connection tests to support sse #1282
• fix(cloudflare-workers): fix aborts on sse streams on cloudflare workers #1281
• fix(cloudflare-workers): fix aborting sse streams #1280
• chore: remove unused FakeEventSource #1279
• 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
• counter
• example-crdt
• example-database
• example-sqlite
• example-elysia
• example-express
• example-game
• example-hono
• example-hono-react
• 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@1288

@rivetkit/cloudflare-workers

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

@rivetkit/core

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

@rivetkit/db

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

@rivetkit/framework-base

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

@rivetkit/next-js

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

@rivetkit/react

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

rivetkit

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

@rivetkit/sql-loader

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

commit: a1ed010

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Provide comprehensive feedback via GitHub comment

Overview

This PR implements serverless support for RivetKit, primarily focused on Next.js integration. The changes introduce a new @rivetkit/next-js package and modify the core router to handle serverless environments better.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing
• Follows established project conventions (camelCase, proper imports)
• Good use of structured logging with logger() calls
• Proper error handling patterns extending ActorError
• Well-organized code structure

Areas for improvement:

• Missing JSDoc documentation for public APIs (particularly toNextHandler)
• Some TODO comments left unresolved

Potential Bugs & Issues ⚠️

High Priority:

1. packages/rivetkit/src/manager/router.ts:291 - Empty name field:

   name: "", // TODO: The API doesn't provide the name, this may need to be resolved

   This could cause issues with actor lookup validation and should be addressed.

2. packages/rivetkit/src/manager/router.ts:136-137 - Unprotected JSON parsing:

   connParams ? JSON.parse(connParams) : undefined,
   authData ? JSON.parse(authData) : undefined,

   These should be wrapped in try-catch blocks to handle malformed JSON gracefully.

Medium Priority:

3. packages/next-js/src/mod.ts:12 - Async params destructuring pattern:

   const { params }: { params: Promise<{ all: string[] }> }

   This suggests Next.js 15 compatibility but should be verified for backward compatibility.

4. URL reconstruction logic in Next.js handler could be brittle - consider validation of the all parameter array.

Performance Considerations ⚡

Concerns identified:

1. Memory buffering (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:27-29):

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This is particularly problematic in serverless environments with memory constraints.

2. Request handling efficiency: The serverless handler creates new Request objects which could be optimized.

Recommendations:

• Implement streaming for large request bodies
• Add request size limits for serverless environments
• Consider connection pooling where applicable

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing: Multiple locations parse JSON without proper error handling (router.ts:136-137)
2. Header propagation: Headers are copied wholesale in buildGuardHeadersForHttp() without sanitization
3. WebSocket proxy complexity: The complex proxy logic could have security implications

Recommendations:

• Add try-catch blocks around all JSON.parse() calls
• Implement header sanitization and validation
• Add input size limits to prevent DoS attacks

Test Coverage 📊

Observations:

• No new test files were added for the serverless functionality
• The Next.js integration lacks test coverage
• WebSocket proxy functionality should have comprehensive error scenario tests

Recommendations:

• Add unit tests for toNextHandler function
• Test error scenarios (malformed JSON, oversized requests)
• Add integration tests for the Next.js serverless workflow

Architecture & Design 🏗️

Positive aspects:

• Clean separation of concerns with the new @rivetkit/next-js package
• Proper use of disableServer: true flag for serverless environments
• Good abstraction of serverless routing logic

Considerations:

• The versioned data handler changes appear sound with proper migration support
• Cache clearing script is comprehensive and well-structured

Specific Technical Feedback

packages/next-js/src/mod.ts:

• Consider adding input validation for the all parameter
• The URL reconstruction logic is correct but could benefit from error handling

packages/rivetkit/src/common/versioned-data.ts:

• Excellent implementation of data versioning with proper error handling
• Migration logic is robust and well-designed

scripts/nuke-cache.sh:

• Comprehensive cache clearing with good safety checks
• Consider adding a dry-run mode for extra safety

Summary

This is a solid serverless implementation that follows the project's coding standards. The main concerns are around error handling for JSON parsing, memory management for request buffering, and some incomplete TODOs.

Priority fixes needed:

1. Fix empty name field in router.ts:291
2. Add try-catch blocks around JSON.parse() calls
3. Address memory buffering TODO or implement size limits
4. Add comprehensive test coverage

Recommended before merge:

• Complete or create issues for remaining TODOs
• Add basic test coverage for serverless functionality
• Consider backward compatibility implications

The architecture and approach are sound, making this a valuable addition to RivetKit's serverless capabilities.

---

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Provide comprehensive feedback via GitHub comment

Overview

This PR implements serverless support for RivetKit, introducing a new @rivetkit/next-js package and enhancing the core router for serverless environments. The implementation follows a clean architectural approach with proper separation of concerns.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing throughout
• Follows established project conventions (camelCase, structured logging)
• Good use of logger() calls with structured logging patterns
• Proper error handling patterns extending ActorError base class
• Well-organized code structure with clear separation of serverless logic

Areas for improvement:

• Missing JSDoc documentation for public APIs, particularly the toNextHandler function in packages/next-js/src/mod.ts:3
• Some TODO comments remain unresolved (see issues section below)

Potential Bugs & Issues ⚠️

High Priority:

1. packages/rivetkit/src/manager/router.ts:291 - Empty name field in actor lookup:

   name: "", // TODO: The API doesn't provide the name, this may need to be resolved

   This could cause validation issues or inconsistent behavior in actor lookups.

2. packages/rivetkit/src/manager/router.ts:136-137 - Unprotected JSON parsing:

   connParams ? JSON.parse(connParams) : undefined,
   authData ? JSON.parse(authData) : undefined,

   These should be wrapped in try-catch blocks to handle malformed JSON gracefully.

Medium Priority:

3. packages/next-js/src/mod.ts:12 - Next.js 15 async params pattern:

   const { params }: { params: Promise<{ all: string[] }> }

   While this supports Next.js 15's async params, backward compatibility should be verified.

4. packages/next-js/src/mod.ts:16 - URL reconstruction lacks validation:

   newUrl.pathname = all.join('/');

   Consider adding validation for the all parameter array to ensure it contains valid path segments.

Performance Considerations ⚡

Concerns identified:

1. Memory buffering issue (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:27-29):

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This is particularly problematic in serverless environments with memory constraints and should be prioritized.

2. Request object creation - The Next.js handler creates new Request objects which could be optimized for better performance.

3. Synchronous JSON parsing - Multiple JSON.parse() calls could benefit from async handling or error boundaries.

Recommendations:

• Implement streaming for large request bodies in serverless environments
• Add request size limits to prevent memory exhaustion
• Consider request/response caching strategies where appropriate

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:136-137)

2. Header propagation (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:67-69):

   for (const [key, value] of actorRequest.headers.entries()) {
     headers.set(key, value);
   }

   Headers are copied wholesale without sanitization, which could lead to header injection attacks.

3. WebSocket proxy complexity - The complex proxy logic in createTestWebSocketProxy could have security implications if not properly validated.

Recommendations:

• Add try-catch blocks around all JSON.parse() operations
• Implement header sanitization and validation
• Add input size limits to prevent DoS attacks
• Consider implementing a whitelist for allowed headers

Test Coverage 📊

Observations:

• No new test files were added for the serverless functionality
• The @rivetkit/next-js package lacks test coverage entirely
• WebSocket proxy functionality should have comprehensive error scenario tests
• Missing integration tests for the Next.js serverless workflow

Recommendations:

• Add unit tests for the toNextHandler function
• Test error scenarios (malformed JSON, oversized requests, invalid paths)
• Add integration tests covering the full serverless request lifecycle
• Test WebSocket functionality under various network conditions

Architecture & Design 🏗️

Positive aspects:

• Clean separation with the new @rivetkit/next-js package
• Proper use of disableServer: true flag for serverless environments
• Well-abstracted serverless routing logic
• Good integration with existing RivetKit patterns

Technical Implementation:

packages/next-js/src/mod.ts - Solid serverless integration:

• URL reconstruction logic is correct but could use input validation
• Proper HTTP method support across GET, POST, PUT, PATCH, HEAD, OPTIONS
• Clean integration with RivetKit's fetch handler

packages/rivetkit/src/common/versioned-data.ts - Excellent implementation:

• Robust data versioning with proper migration support
• Good error handling for version mismatches and invalid data
• Clean separation of serialization/deserialization concerns

scripts/nuke-cache.sh - Comprehensive cache management:

• Good safety checks with directory existence validation
• Covers all major JavaScript build cache directories
• Consider adding a dry-run mode for extra safety

Summary

This is a well-architected serverless implementation that follows RivetKit's coding standards and conventions. The core functionality is sound, but there are several areas requiring attention before merge.

Critical fixes needed:

1. Resolve empty name field in router.ts:291
2. Add error handling for JSON parsing operations
3. Address memory buffering TODO or implement size limits

Recommended improvements:

• Add comprehensive test coverage for serverless functionality
• Implement header validation and sanitization
• Add JSDoc documentation for public APIs
• Complete remaining TODO items or create issues for them

Overall Assessment: The implementation provides solid serverless support for RivetKit with good architectural decisions. With the identified issues addressed, this will be a valuable addition to the framework.

---

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Provide comprehensive feedback

---

Overview

This PR implements serverless support for RivetKit, introducing a new @rivetkit/next-js package and enhancing the core router for serverless environments. The implementation follows a clean architectural approach with proper separation of concerns.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing throughout
• Follows established project conventions (camelCase, structured logging with logger())
• Good use of error handling patterns extending ActorError base class
• Well-organized code structure with clear separation of serverless logic
• Consistent import patterns and workspace package usage

Areas for improvement:

• Missing JSDoc documentation for public APIs, particularly the toNextHandler function in packages/next-js/src/mod.ts:3
• Some TODO comments remain unresolved (detailed in issues section)

Potential Bugs & Issues ⚠️

High Priority:

1. packages/rivetkit/src/manager/router.ts:291 - Empty name field in actor lookup:

   name: "", // TODO: The API doesn't provide the name, this may need to be resolved

   This could cause validation issues or inconsistent behavior in actor lookups. The API should either provide the name or handle this case properly.

2. packages/rivetkit/src/manager/router.ts:136-137 - Unprotected JSON parsing:

   connParams ? JSON.parse(connParams) : undefined,
   authData ? JSON.parse(authData) : undefined,

   These should be wrapped in try-catch blocks to handle malformed JSON gracefully. Malformed JSON could cause the entire request to fail.

Medium Priority:

3. packages/next-js/src/mod.ts:12 - Next.js 15 async params pattern:

   const { params }: { params: Promise<{ all: string[] }> }

   While this supports Next.js 15's async params, backward compatibility should be verified for users on older Next.js versions.

4. packages/next-js/src/mod.ts:16 - URL reconstruction lacks validation:

   newUrl.pathname = all.join('/');

   Consider adding validation for the all parameter array to ensure it contains valid path segments and prevent potential path injection.

Performance Considerations ⚡

Critical concerns:

1. Memory buffering issue (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:27-29):

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This is particularly problematic in serverless environments with memory constraints. Large request bodies could cause memory exhaustion or cold start performance issues.

2. Request object creation overhead - The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.

3. Synchronous JSON parsing - Multiple JSON.parse() calls could benefit from async handling or error boundaries to prevent blocking.

Recommendations:

• Implement streaming for large request bodies in serverless environments
• Add request size limits to prevent memory exhaustion
• Consider implementing request/response caching strategies where appropriate
• Add performance monitoring for serverless cold starts

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:136-137, engine/actor-driver.ts:311-312)

2. Header propagation without sanitization (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:67-69):

   for (const [key, value] of actorRequest.headers.entries()) {
     headers.set(key, value);
   }

   Headers are copied wholesale without sanitization, which could lead to header injection attacks or information leakage.

3. Path injection potential in Next.js handler - The all parameter is directly used to construct pathnames without validation.

4. WebSocket proxy complexity - The complex proxy logic in createTestWebSocketProxy could have security implications if not properly validated.

Recommendations:

• Add try-catch blocks around all JSON.parse() operations
• Implement header sanitization and validation (whitelist allowed headers)
• Add input size limits and validation to prevent DoS attacks
• Validate path segments in the Next.js handler

Test Coverage 📊

Critical gaps:

• No new test files were added for the serverless functionality
• The @rivetkit/next-js package lacks any test coverage
• WebSocket proxy functionality has no test coverage for error scenarios
• Missing integration tests for the Next.js serverless workflow

Recommendations:

• Add unit tests for the toNextHandler function covering various HTTP methods
• Test error scenarios (malformed JSON, oversized requests, invalid paths)
• Add integration tests covering the full serverless request lifecycle
• Test WebSocket functionality under various network conditions and error states
• Add tests for the versioned data migration logic

Architecture & Design 🏗️

Positive aspects:

• Clean separation with the new @rivetkit/next-js package
• Proper use of disableServer: true flag for serverless environments
• Well-abstracted serverless routing logic
• Good integration with existing RivetKit patterns and error handling

Technical Implementation Analysis:

packages/next-js/src/mod.ts - Solid serverless integration:

• Clean URL reconstruction but needs input validation
• Comprehensive HTTP method support (GET, POST, PUT, PATCH, HEAD, OPTIONS)
• Good integration with RivetKit's fetch handler pattern

packages/rivetkit/src/common/versioned-data.ts - Excellent implementation:

• Robust data versioning with proper migration support
• Good error handling for version mismatches and invalid data
• Clean separation of serialization/deserialization concerns
• Proper validation of version bounds

scripts/nuke-cache.sh - Comprehensive cache management:

• Good safety checks with directory existence validation
• Covers all major JavaScript build cache directories
• Consider adding a dry-run mode for extra safety

Specific Technical Feedback

Engine Actor Driver Changes:

• The serverless start endpoint implementation looks solid
• Good use of Server-Sent Events for health monitoring
• Proper async handling throughout

Router Improvements:

• Better CORS handling and request routing
• Comprehensive WebSocket proxy implementation
• Good error handling patterns

Summary

This is a well-architected serverless implementation that follows RivetKit's coding standards and design patterns. The core functionality is sound and the approach is scalable, but there are several critical issues that need attention before merge.

Critical fixes needed before merge:

1. Resolve empty name field in router.ts:291 - this could cause runtime failures
2. Add error handling for all JSON parsing operations to prevent crashes
3. Address memory buffering TODO or implement size limits for production use

High priority improvements:

• Add comprehensive test coverage for serverless functionality
• Implement header validation and sanitization for security
• Add input validation for path segments and request parameters
• Complete remaining TODO items or create issues for future work

Overall Assessment: This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. With the identified issues addressed, this will be a valuable addition to the framework's deployment options. The versioned data handling and routing improvements are particularly well-implemented.

---

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Provide comprehensive feedback

---

Overview

This PR implements serverless support for RivetKit, introducing a new @rivetkit/next-js package and enhancing the core router for serverless environments. The implementation follows a clean architectural approach with proper separation of concerns.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing throughout
• Follows established project conventions (camelCase, structured logging with logger())
• Good use of error handling patterns extending ActorError base class
• Well-organized code structure with clear separation of serverless logic
• Consistent import patterns and workspace package usage

Areas for improvement:

• Missing JSDoc documentation for public APIs, particularly the toNextHandler function in packages/next-js/src/mod.ts:3
• Some TODO comments remain unresolved (detailed in issues section)

Potential Bugs & Issues ⚠️

High Priority:

1. packages/rivetkit/src/manager/router.ts:291 - Empty name field in actor lookup:

   name: "", // TODO: The API doesn't provide the name, this may need to be resolved

   This could cause validation issues or inconsistent behavior in actor lookups. The API should either provide the name or handle this case properly.

2. packages/rivetkit/src/manager/router.ts:136-137 - Unprotected JSON parsing:

   connParams ? JSON.parse(connParams) : undefined,
   authData ? JSON.parse(authData) : undefined,

   These should be wrapped in try-catch blocks to handle malformed JSON gracefully. Malformed JSON could cause the entire request to fail.

Medium Priority:

3. packages/next-js/src/mod.ts:12 - Next.js 15 async params pattern:

   const { params }: { params: Promise<{ all: string[] }> }

   While this supports Next.js 15's async params, backward compatibility should be verified for users on older Next.js versions.

4. packages/next-js/src/mod.ts:16 - URL reconstruction lacks validation:

   newUrl.pathname = all.join('/');

   Consider adding validation for the all parameter array to ensure it contains valid path segments and prevent potential path injection.

Performance Considerations ⚡

Critical concerns:

1. Memory buffering issue (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:27-29):

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This is particularly problematic in serverless environments with memory constraints. Large request bodies could cause memory exhaustion or cold start performance issues.

2. Request object creation overhead - The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.

3. Synchronous JSON parsing - Multiple JSON.parse() calls could benefit from async handling or error boundaries to prevent blocking.

Recommendations:

• Implement streaming for large request bodies in serverless environments
• Add request size limits to prevent memory exhaustion
• Consider implementing request/response caching strategies where appropriate
• Add performance monitoring for serverless cold starts

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:136-137, engine/actor-driver.ts:311-312)

2. Header propagation without sanitization (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:67-69):

   for (const [key, value] of actorRequest.headers.entries()) {
     headers.set(key, value);
   }

   Headers are copied wholesale without sanitization, which could lead to header injection attacks or information leakage.

3. Path injection potential in Next.js handler - The all parameter is directly used to construct pathnames without validation.

4. WebSocket proxy complexity - The complex proxy logic in createTestWebSocketProxy could have security implications if not properly validated.

Recommendations:

• Add try-catch blocks around all JSON.parse() operations
• Implement header sanitization and validation (whitelist allowed headers)
• Add input size limits and validation to prevent DoS attacks
• Validate path segments in the Next.js handler

Test Coverage 📊

Critical gaps:

• No new test files were added for the serverless functionality
• The @rivetkit/next-js package lacks any test coverage
• WebSocket proxy functionality has no test coverage for error scenarios
• Missing integration tests for the Next.js serverless workflow

Recommendations:

• Add unit tests for the toNextHandler function covering various HTTP methods
• Test error scenarios (malformed JSON, oversized requests, invalid paths)
• Add integration tests covering the full serverless request lifecycle
• Test WebSocket functionality under various network conditions and error states
• Add tests for the versioned data migration logic

Architecture & Design 🏗️

Positive aspects:

• Clean separation with the new @rivetkit/next-js package
• Proper use of disableServer: true flag for serverless environments
• Well-abstracted serverless routing logic
• Good integration with existing RivetKit patterns and error handling

Technical Implementation Analysis:

packages/next-js/src/mod.ts - Solid serverless integration:

• Clean URL reconstruction but needs input validation
• Comprehensive HTTP method support (GET, POST, PUT, PATCH, HEAD, OPTIONS)
• Good integration with RivetKit's fetch handler pattern

packages/rivetkit/src/common/versioned-data.ts - Excellent implementation:

• Robust data versioning with proper migration support
• Good error handling for version mismatches and invalid data
• Clean separation of serialization/deserialization concerns
• Proper validation of version bounds

scripts/nuke-cache.sh - Comprehensive cache management:

• Good safety checks with directory existence validation
• Covers all major JavaScript build cache directories
• Consider adding a dry-run mode for extra safety

Specific Technical Feedback

Engine Actor Driver Changes:

• The serverless start endpoint implementation looks solid
• Good use of Server-Sent Events for health monitoring
• Proper async handling throughout

Router Improvements:

• Better CORS handling and request routing
• Comprehensive WebSocket proxy implementation
• Good error handling patterns

Summary

This is a well-architected serverless implementation that follows RivetKit's coding standards and design patterns. The core functionality is sound and the approach is scalable, but there are several critical issues that need attention before merge.

Critical fixes needed before merge:

1. Resolve empty name field in router.ts:291 - this could cause runtime failures
2. Add error handling for all JSON parsing operations to prevent crashes
3. Address memory buffering TODO or implement size limits for production use

High priority improvements:

• Add comprehensive test coverage for serverless functionality
• Implement header validation and sanitization for security
• Add input validation for path segments and request parameters
• Complete remaining TODO items or create issues for future work

Overall Assessment: This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. With the identified issues addressed, this will be a valuable addition to the framework's deployment options. The versioned data handling and routing improvements are particularly well-implemented.

---

View job

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Provide comprehensive feedback via GitHub comment

---

Overview

This PR implements serverless support for RivetKit, introducing a new @rivetkit/next-js package and enhancing the core router for serverless environments. The implementation follows a clean architectural approach with proper separation of concerns.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing throughout
• Follows established project conventions (camelCase, structured logging with logger())
• Good use of error handling patterns extending ActorError base class
• Well-organized code structure with clear separation of serverless logic
• Consistent import patterns and workspace package usage

Areas for improvement:

• Missing JSDoc documentation for public APIs, particularly the toNextHandler function in packages/next-js/src/mod.ts:3
• Some TODO comments remain unresolved (detailed in issues section)

Potential Bugs & Issues ⚠️

High Priority:

1. packages/rivetkit/src/manager/router.ts:292 - Empty name field in actor lookup:

   name: "", // TODO: The API doesn't provide the name, this may need to be resolved

   This could cause validation issues or inconsistent behavior in actor lookups. The API should either provide the name or handle this case properly.

2. packages/rivetkit/src/manager/router.ts:137-138 - Unprotected JSON parsing:

   connParams ? JSON.parse(connParams) : undefined,
   authData ? JSON.parse(authData) : undefined,

   These should be wrapped in try-catch blocks to handle malformed JSON gracefully. Malformed JSON could cause the entire request to fail.

3. packages/rivetkit/src/drivers/engine/actor-driver.ts:311-312 - Additional unprotected JSON parsing:

   const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
   const authData = authDataRaw ? JSON.parse(authDataRaw) : undefined;

Medium Priority:

4. packages/next-js/src/mod.ts:13 - Next.js 15 async params pattern:

   const { params }: { params: Promise<{ all: string[] }> }

   While this supports Next.js 15's async params, backward compatibility should be verified for users on older Next.js versions.

5. packages/next-js/src/mod.ts:17 - URL reconstruction lacks validation:

   newUrl.pathname = all.join('/');

   Consider adding validation for the all parameter array to ensure it contains valid path segments and prevent potential path injection.

Performance Considerations ⚡

Critical concerns:

1. Memory buffering issue (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:27-29):

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This is particularly problematic in serverless environments with memory constraints. Large request bodies could cause memory exhaustion or cold start performance issues.

2. Request object creation overhead - The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.

3. Synchronous JSON parsing - Multiple JSON.parse() calls could benefit from async handling or error boundaries to prevent blocking.

Recommendations:

• Implement streaming for large request bodies in serverless environments
• Add request size limits to prevent memory exhaustion
• Consider implementing request/response caching strategies where appropriate
• Add performance monitoring for serverless cold starts

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:137-138, engine/actor-driver.ts:311-312)

2. Header propagation without sanitization (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:67-69):

   for (const [key, value] of actorRequest.headers.entries()) {
     headers.set(key, value);
   }

   Headers are copied wholesale without sanitization, which could lead to header injection attacks or information leakage.

3. Path injection potential in Next.js handler - The all parameter is directly used to construct pathnames without validation.

4. WebSocket proxy complexity - The complex proxy logic in createTestWebSocketProxy could have security implications if not properly validated.

Recommendations:

• Add try-catch blocks around all JSON.parse() operations
• Implement header sanitization and validation (whitelist allowed headers)
• Add input size limits and validation to prevent DoS attacks
• Validate path segments in the Next.js handler

Test Coverage 📊

Critical gaps:

• No new test files were added for the serverless functionality
• The @rivetkit/next-js package lacks any test coverage
• WebSocket proxy functionality has no test coverage for error scenarios
• Missing integration tests for the Next.js serverless workflow

Recommendations:

• Add unit tests for the toNextHandler function covering various HTTP methods
• Test error scenarios (malformed JSON, oversized requests, invalid paths)
• Add integration tests covering the full serverless request lifecycle
• Test WebSocket functionality under various network conditions and error states
• Add tests for the versioned data migration logic

Architecture & Design 🏗️

Positive aspects:

• Clean separation with the new @rivetkit/next-js package
• Proper use of disableServer: true flag for serverless environments
• Well-abstracted serverless routing logic
• Good integration with existing RivetKit patterns and error handling

Technical Implementation Analysis:

packages/next-js/src/mod.ts - Solid serverless integration:

• Clean URL reconstruction but needs input validation
• Comprehensive HTTP method support (GET, POST, PUT, PATCH, HEAD, OPTIONS)
• Good integration with RivetKit's fetch handler pattern

packages/rivetkit/src/common/versioned-data.ts - Excellent implementation:

• Robust data versioning with proper migration support
• Good error handling for version mismatches and invalid data
• Clean separation of serialization/deserialization concerns
• Proper validation of version bounds

scripts/nuke-cache.sh - Comprehensive cache management:

• Good safety checks with directory existence validation
• Covers all major JavaScript build cache directories
• Consider adding a dry-run mode for extra safety

Specific Technical Feedback

Engine Actor Driver Changes:

• The serverless start endpoint implementation looks solid
• Good use of Server-Sent Events for health monitoring
• Proper async handling throughout

Router Improvements:

• Better CORS handling and request routing
• Comprehensive WebSocket proxy implementation
• Good error handling patterns

Summary

This is a well-architected serverless implementation that follows RivetKit's coding standards and design patterns. The core functionality is sound and the approach is scalable, but there are several critical issues that need attention before merge.

Critical fixes needed before merge:

1. Resolve empty name field in router.ts:292 - this could cause runtime failures
2. Add error handling for all JSON parsing operations to prevent crashes
3. Address memory buffering TODO or implement size limits for production use

High priority improvements:

• Add comprehensive test coverage for serverless functionality
• Implement header validation and sanitization for security
• Add input validation for path segments and request parameters
• Complete remaining TODO items or create issues for future work

Overall Assessment: This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. With the identified issues addressed, this will be a valuable addition to the framework's deployment options. The versioned data handling and routing improvements are particularly well-implemented.

---

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: feat: serverless

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze changed files for code quality and best practices
• Check for potential bugs and issues
• Evaluate performance considerations
• Identify security concerns
• Assess test coverage implications
• Provide comprehensive feedback

---

Overview

This PR implements serverless support for RivetKit, introducing a new @rivetkit/next-js package and enhancing the core router for serverless environments. The implementation follows a clean architectural approach with proper separation of concerns.

Code Quality & Best Practices ✅

Positive aspects:

• Clean TypeScript implementation with proper typing throughout
• Follows established project conventions (camelCase, structured logging with logger())
• Good use of error handling patterns extending ActorError base class
• Well-organized code structure with clear separation of serverless logic
• Consistent import patterns and workspace package usage

Areas for improvement:

• Missing JSDoc documentation for public APIs, particularly the toNextHandler function in packages/next-js/src/mod.ts:3
• Some TODO comments remain unresolved (detailed in issues section)

Potential Bugs & Issues ⚠️

High Priority:

1. packages/rivetkit/src/manager/router.ts:292 - Empty name field in actor lookup:

   name: "", // TODO: The API doesn't provide the name, this may need to be resolved

   This could cause validation issues or inconsistent behavior in actor lookups. The API should either provide the name or handle this case properly.

2. packages/rivetkit/src/manager/router.ts:137-138 - Unprotected JSON parsing:

   connParams ? JSON.parse(connParams) : undefined,
   authData ? JSON.parse(authData) : undefined,

   These should be wrapped in try-catch blocks to handle malformed JSON gracefully. Malformed JSON could cause the entire request to fail.

3. packages/rivetkit/src/drivers/engine/actor-driver.ts:311-312 - Additional unprotected JSON parsing:

   const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
   const authData = authDataRaw ? JSON.parse(authDataRaw) : undefined;

Medium Priority:

4. packages/next-js/src/mod.ts:13 - Next.js 15 async params pattern:

   const { params }: { params: Promise<{ all: string[] }> }

   While this supports Next.js 15's async params, backward compatibility should be verified for users on older Next.js versions.

5. packages/next-js/src/mod.ts:17 - URL reconstruction lacks validation:

   newUrl.pathname = all.join('/');

   Consider adding validation for the all parameter array to ensure it contains valid path segments and prevent potential path injection.

Performance Considerations ⚡

Critical concerns:

1. Memory buffering issue (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:27-29):

   // TODO: This buffers the entire request in memory every time. We
   // need to properly implement streaming bodies.

   This is particularly problematic in serverless environments with memory constraints. Large request bodies could cause memory exhaustion or cold start performance issues.

2. Request object creation overhead - The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.

3. Synchronous JSON parsing - Multiple JSON.parse() calls could benefit from async handling or error boundaries to prevent blocking.

Recommendations:

• Implement streaming for large request bodies in serverless environments
• Add request size limits to prevent memory exhaustion
• Consider implementing request/response caching strategies where appropriate
• Add performance monitoring for serverless cold starts

Security Concerns 🔒

Issues identified:

1. Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:137-138, engine/actor-driver.ts:311-312)

2. Header propagation without sanitization (packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:67-69):

   for (const [key, value] of actorRequest.headers.entries()) {
     headers.set(key, value);
   }

   Headers are copied wholesale without sanitization, which could lead to header injection attacks or information leakage.

3. Path injection potential in Next.js handler - The all parameter is directly used to construct pathnames without validation.

4. WebSocket proxy complexity - The complex proxy logic in createTestWebSocketProxy could have security implications if not properly validated.

Recommendations:

• Add try-catch blocks around all JSON.parse() operations
• Implement header sanitization and validation (whitelist allowed headers)
• Add input size limits and validation to prevent DoS attacks
• Validate path segments in the Next.js handler

Test Coverage 📊

Critical gaps:

• No new test files were added for the serverless functionality
• The @rivetkit/next-js package lacks any test coverage
• WebSocket proxy functionality has no test coverage for error scenarios
• Missing integration tests for the Next.js serverless workflow

Recommendations:

• Add unit tests for the toNextHandler function covering various HTTP methods
• Test error scenarios (malformed JSON, oversized requests, invalid paths)
• Add integration tests covering the full serverless request lifecycle
• Test WebSocket functionality under various network conditions and error states
• Add tests for the versioned data migration logic

Architecture & Design 🏗️

Positive aspects:

• Clean separation with the new @rivetkit/next-js package
• Proper use of disableServer: true flag for serverless environments
• Well-abstracted serverless routing logic
• Good integration with existing RivetKit patterns and error handling

Technical Implementation Analysis:

packages/next-js/src/mod.ts - Solid serverless integration:

• Clean URL reconstruction but needs input validation
• Comprehensive HTTP method support (GET, POST, PUT, PATCH, HEAD, OPTIONS)
• Good integration with RivetKit's fetch handler pattern

packages/rivetkit/src/common/versioned-data.ts - Excellent implementation:

• Robust data versioning with proper migration support
• Good error handling for version mismatches and invalid data
• Clean separation of serialization/deserialization concerns
• Proper validation of version bounds

scripts/nuke-cache.sh - Comprehensive cache management:

• Good safety checks with directory existence validation
• Covers all major JavaScript build cache directories
• Consider adding a dry-run mode for extra safety

Specific Technical Feedback

Engine Actor Driver Changes:

• The serverless start endpoint implementation looks solid
• Good use of Server-Sent Events for health monitoring
• Proper async handling throughout

Router Improvements:

• Better CORS handling and request routing
• Comprehensive WebSocket proxy implementation
• Good error handling patterns

Summary

This is a well-architected serverless implementation that follows RivetKit's coding standards and design patterns. The core functionality is sound and the approach is scalable, but there are several critical issues that need attention before merge.

Critical fixes needed before merge:

1. Resolve empty name field in router.ts:292 - this could cause runtime failures
2. Add error handling for all JSON parsing operations to prevent crashes
3. Address memory buffering TODO or implement size limits for production use

High priority improvements:

• Add comprehensive test coverage for serverless functionality
• Implement header validation and sanitization for security
• Add input validation for path segments and request parameters
• Complete remaining TODO items or create issues for future work

Overall Assessment: This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. With the identified issues addressed, this will be a valuable addition to the framework's deployment options. The versioned data handling and routing improvements are particularly well-implemented.

---

[linear]

KIT-288 Serverless runner integration