feat: serverless #1288

MasterPtato · 2025-09-18T22:08:43Z

Fixes KIT-288

vercel · 2025-09-18T22:08:48Z

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

Project	Deployment	Preview	Comments	Updated (UTC)
rivetkit-serverless	Error			Sep 26, 2025 0:42am

claude · 2025-09-18T22:08:55Z

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:

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.
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.

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:

Memory buffering (actor-http-client.ts:29) - Full request buffering could be problematic in memory-constrained serverless environments
Synchronous JSON parsing - Multiple instances of JSON.parse() without async handling could block the event loop
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:

Unvalidated JSON parsing - Multiple locations parse JSON headers without validation (router.ts:135-136)
Header injection potential - Headers are copied wholesale in buildGuardHeadersForHttp() without sanitization
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:

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

MasterPtato · 2025-09-18T22:09:07Z

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

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 · 2025-09-18T22:10:29Z

More templates

@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 · 2025-09-19T18:27:11Z

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:

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.
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:

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.
URL reconstruction logic in Next.js handler could be brittle - consider validation of the all parameter array.

Performance Considerations ⚡

Concerns identified:

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.
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:

Unvalidated JSON parsing: Multiple locations parse JSON without proper error handling (router.ts:136-137)
Header propagation: Headers are copied wholesale in buildGuardHeadersForHttp() without sanitization
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:

Fix empty name field in router.ts:291
Add try-catch blocks around JSON.parse() calls
Address memory buffering TODO or implement size limits
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 · 2025-09-19T18:34:03Z

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:

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.
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:

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.
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:

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.
Request object creation - The Next.js handler creates new Request objects which could be optimized for better performance.
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:

Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:136-137)
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.
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:

Resolve empty name field in router.ts:291
Add error handling for JSON parsing operations
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 · 2025-09-19T19:24:38Z

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:

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.
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:

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.
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:

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.
Request object creation overhead - The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.
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:

Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:136-137, engine/actor-driver.ts:311-312)
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.
Path injection potential in Next.js handler - The all parameter is directly used to construct pathnames without validation.
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:

Resolve empty name field in router.ts:291 - this could cause runtime failures
Add error handling for all JSON parsing operations to prevent crashes
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 · 2025-09-19T19:31:32Z

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:

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.
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:

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.
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:

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.
Request object creation overhead - The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.
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:

Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:136-137, engine/actor-driver.ts:311-312)
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.
Path injection potential in Next.js handler - The all parameter is directly used to construct pathnames without validation.
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:

Resolve empty name field in router.ts:291 - this could cause runtime failures
Add error handling for all JSON parsing operations to prevent crashes
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 · 2025-09-19T20:08:46Z

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:

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.
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.

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:

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.
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:

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.
Request object creation overhead - The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.
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:

Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:137-138, engine/actor-driver.ts:311-312)
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.
Path injection potential in Next.js handler - The all parameter is directly used to construct pathnames without validation.
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:

Resolve empty name field in router.ts:292 - this could cause runtime failures
Add error handling for all JSON parsing operations to prevent crashes
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 · 2025-09-19T21:19:44Z

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:

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.
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.

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:

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.
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:

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.
Request object creation overhead - The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.
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:

Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:137-138, engine/actor-driver.ts:311-312)
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.
Path injection potential in Next.js handler - The all parameter is directly used to construct pathnames without validation.
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:

Resolve empty name field in router.ts:292 - this could cause runtime failures
Add error handling for all JSON parsing operations to prevent crashes
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 · 2025-09-19T21:27:43Z

KIT-288 Serverless runner integration

packages/rivetkit/src/manager/router.ts

claude · 2025-09-26T00:02:33Z

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
Address review comment about disabling endpoints in serverless mode
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:

packages/rivetkit/src/manager/router.ts:354 - Unprotected JSON parsing in WebSocket handler:
```
params = JSON.parse(paramsRaw);
```
This should be wrapped in try-catch to handle malformed JSON gracefully.

packages/rivetkit/src/manager/gateway.ts:100 - Unprotected JSON parsing:

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

packages/rivetkit/src/drivers/engine/actor-driver.ts:328 - Unprotected JSON parsing:
```
const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
```
packages/rivetkit/src/actor/router.ts:89, 180 - Multiple unprotected JSON parsing instances:
```
const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
```

All these JSON parsing operations could cause the entire request to fail if malformed JSON is provided.

Medium Priority:

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.
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:

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.
Request object creation overhead - The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.

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:

Unvalidated JSON parsing - Multiple locations parse JSON without proper error handling (router.ts:354, gateway.ts:100, engine/actor-driver.ts:328, actor/router.ts:89,180)
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.
Path injection potential in Next.js handler - The all parameter is directly used to construct pathnames without validation.

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

Review Comment: Disabling Endpoints in Serverless Mode 🎯

The review comment correctly identifies that when the serverless driver is enabled, other endpoints should be disabled. Currently, the code adds /start and /health endpoints when serverlessActorDriverBuilder is present, but it doesn't disable the existing management endpoints like:

GET / - Welcome endpoint
GET /actors - List actors
PUT /actors - Get or create actors
POST /actors - Create actors
Test endpoints (.test/inline-driver/call)
Inspector endpoints (/inspect)

Recommendation: Wrap the existing endpoint definitions in a conditional check to disable them when running in serverless mode:

if (!serverlessActorDriverBuilder) {
  // Existing endpoints like GET /, GET /actors, etc.
}

Test Coverage 📊

Critical gaps:

No new test files were added for the serverless functionality
The @rivetkit/next-js package lacks any test coverage
Missing integration tests for the Next.js serverless workflow
No error scenario testing for JSON parsing failures

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 the new versioned data migration logic

Architecture & Design 🏗️

Positive aspects:

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

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

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:

Add error handling for all JSON parsing operations to prevent crashes
Address the reviewer's concern about disabling non-serverless endpoints when in serverless mode
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 · 2025-09-26T00:02:42Z

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
Address review comment about endpoint disabling
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)

Critical Issues ⚠️

1. Review Comment Issue - Endpoint Access Control (HIGH PRIORITY)
The review comment at packages/rivetkit/src/manager/router.ts:444 correctly identifies that all other endpoints should be disabled when serverless driver is enabled. Currently, when serverlessActorDriverBuilder is present (serverless mode), the code only adds /start and /health endpoints but still exposes:

GET / (root endpoint)
GET /actors (actor listing)
PUT /actors (get or create actors)
POST /actors (create actors)
Test endpoints (.test/inline-driver/*)
Inspector endpoints (/inspect/*)

This is a security and architectural concern - serverless environments should have a minimal attack surface and controlled endpoint exposure.

2. Unprotected JSON Parsing (HIGH PRIORITY)
Multiple locations parse JSON without proper error handling, which could cause crashes:

packages/rivetkit/src/manager/gateway.ts:100: const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
packages/rivetkit/src/drivers/engine/actor-driver.ts:328: const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
packages/rivetkit/src/manager/router.ts:354: params = JSON.parse(paramsRaw);

3. URL Reconstruction Vulnerability (MEDIUM PRIORITY)
In packages/next-js/src/mod.ts:17:

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

The all parameter from Next.js params is used directly without validation, potentially allowing path injection attacks.

Performance Concerns ⚡

1. Memory Buffering Issue (CRITICAL for Serverless)
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.
const reqBody = await actorRequest.arrayBuffer();

This is particularly problematic in serverless environments with memory constraints and could cause cold start 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.

Security Concerns 🔒

1. Header Propagation Without Sanitization
packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:67-69 - Headers are copied wholesale without validation, potentially allowing header injection attacks.

2. Missing Input Validation

No size limits on request bodies or parameters
Path segments in Next.js handler aren't validated
JSON parsing without error boundaries

Test Coverage 📊

Critical gaps:

No test files added for serverless functionality
The @rivetkit/next-js package lacks any test coverage
Missing integration tests for serverless workflow
No tests for error scenarios (malformed JSON, invalid paths)

Architecture & Design 🏗️

Positive aspects:

Clean separation with the new @rivetkit/next-js package
Proper use of disableServer: true and disableActorDriver: true flags
Good integration with existing RivetKit patterns
Versioned data handler is well-implemented with proper migration support

Technical Implementation Analysis:

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

Clean URL reconstruction but needs input validation
Comprehensive HTTP method support
Proper configuration flags for serverless mode

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

Robust data versioning with proper migration support
Good error handling for version mismatches
Clean separation of serialization concerns

scripts/nuke-cache.sh - Well-structured cache management:

Comprehensive coverage of JavaScript build cache directories
Good safety checks and colored output

Recommendations

Critical fixes needed before merge:

Implement endpoint access control for serverless mode - When serverlessActorDriverBuilder is present, disable or restrict access to non-essential endpoints
Add try-catch blocks around all JSON.parse() operations to prevent crashes
Address memory buffering TODO or implement request size limits for production use
Add input validation for path segments in Next.js handler

High priority improvements:

Add comprehensive test coverage for serverless functionality
Implement header validation and sanitization
Add request size limits to prevent DoS attacks
Complete remaining TODO items or create issues for future work

Medium priority:

Add JSDoc documentation for public APIs
Consider backward compatibility for Next.js versions
Implement dry-run mode for cache clearing script

Summary

This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. The core functionality is sound, but the critical issue identified in the review comment about endpoint access control must be addressed before merge. The versioned data handling and routing improvements are particularly well-implemented.

Overall Assessment: With the identified security and access control issues addressed, this will be a valuable addition to RivetKit's deployment options.

claude · 2025-09-26T00:42:16Z

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
Address review comment about endpoint disabling
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)

Critical Issues ⚠️

1. Review Comment Issue - Endpoint Access Control (HIGH PRIORITY)
The review comment at packages/rivetkit/src/manager/router.ts:93-97 correctly identifies that all other endpoints should be disabled when serverless driver is enabled. Currently, when serverlessActorDriverBuilder is present (serverless mode), the code only adds /start and /health endpoints via addServerlessRoutes(), but when it's not present, addManagerRoutes() exposes:

GET / (root endpoint)
GET /actors (actor listing - lines 150-221)
PUT /actors (get or create actors - lines 223-274)
POST /actors (create actors - lines 276-313)
Test endpoints (.test/inline-driver/* - lines 343, 371, 431)
Inspector endpoints (/inspect/* - lines 499-514)

This is a security and architectural concern - serverless environments should have a minimal attack surface and controlled endpoint exposure. The current implementation means ALL these management endpoints are still accessible even in serverless mode.

2. Unprotected JSON Parsing (HIGH PRIORITY)
Multiple locations parse JSON without proper error handling, which could cause crashes:

packages/rivetkit/src/manager/gateway.ts:100: const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
packages/rivetkit/src/drivers/engine/actor-driver.ts:328: const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
packages/rivetkit/src/manager/router.ts:406: params = JSON.parse(paramsRaw);

3. URL Reconstruction Vulnerability (MEDIUM PRIORITY)
In packages/next-js/src/mod.ts:20:

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

The all parameter from Next.js params is used directly without validation, potentially allowing path injection attacks.

Performance Concerns ⚡

1. Memory Buffering Issue (CRITICAL for Serverless)
packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:24-26:

// TODO: This buffers the entire request in memory every time. We
// need to properly implement streaming bodies.
const reqBody = await actorRequest.arrayBuffer();

This is particularly problematic in serverless environments with memory constraints and could cause cold start issues or memory exhaustion.

2. Request Object Creation Overhead
The Next.js handler creates new Request objects for each invocation, which could impact performance in high-traffic scenarios.

Security Concerns 🔒

1. Header Propagation Without Sanitization
packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:61-63 - Headers are copied wholesale without validation:

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

This could potentially allow header injection attacks or information leakage.

2. Missing Input Validation

No size limits on request bodies or parameters
Path segments in Next.js handler aren't validated
JSON parsing without error boundaries

Test Coverage 📊

Critical gaps:

No test files added for the serverless functionality
The @rivetkit/next-js package lacks any test coverage
Missing integration tests for serverless workflow
No tests for error scenarios (malformed JSON, invalid paths)

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

Architecture & Design 🏗️

Positive aspects:

Clean separation with the new @rivetkit/next-js package
Proper use of disableServer: true and disableActorDriver: true flags
Good integration with existing RivetKit patterns
Versioned data handler is well-implemented with proper migration support

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)
Proper configuration flags for serverless mode

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

Robust data versioning with proper migration support (lines 36-62)
Good error handling for version mismatches (lines 41-45, 52-55)
Clean separation of serialization concerns
Proper validation of version bounds

scripts/nuke-cache.sh - Well-structured cache management:

Comprehensive coverage of JavaScript build cache directories (lines 33-53)
Good safety checks and colored output
Consider adding a dry-run mode for extra safety

Summary

This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. The core functionality is sound, but the critical issue identified in the review comment about endpoint access control must be addressed before merge.

Critical fixes needed before merge:

Implement endpoint access control for serverless mode - When serverlessActorDriverBuilder is present, ensure addManagerRoutes() is not called or its endpoints are disabled
Add try-catch blocks around all JSON.parse() operations to prevent crashes
Address memory buffering TODO or implement request 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

Medium priority:

Add JSDoc documentation for public APIs
Consider backward compatibility for Next.js versions
Implement dry-run mode for cache clearing script

Overall Assessment: With the identified security and access control issues addressed, this will be a valuable addition to RivetKit's deployment options. The versioned data handling and routing improvements are particularly well-implemented.

View job

claude · 2025-09-26T00:42:20Z

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
Address the review comment about disabling endpoints in serverless mode
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)

Critical Issues ⚠️

1. Review Comment Issue - Endpoint Access Control (HIGH PRIORITY)
The review comment at packages/rivetkit/src/manager/router.ts:93-97 correctly identifies that all other endpoints should be disabled when serverless driver is enabled. Currently, when serverlessActorDriverBuilder is present (serverless mode), the code only adds /start and /health endpoints but still exposes:

GET / (root endpoint)
GET /actors (actor listing)
PUT /actors (get or create actors)
POST /actors (create actors)
Test endpoints (.test/inline-driver/*)
Inspector endpoints (/inspect/*)

This is a security and architectural concern - serverless environments should have a minimal attack surface and controlled endpoint exposure.

2. Unprotected JSON Parsing (HIGH PRIORITY)
Multiple locations parse JSON without proper error handling, which could cause crashes:

packages/rivetkit/src/manager/gateway.ts:100: const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
packages/rivetkit/src/drivers/engine/actor-driver.ts:328: const connParams = connParamsRaw ? JSON.parse(connParamsRaw) : undefined;
packages/rivetkit/src/manager/router.ts:406: params = JSON.parse(paramsRaw);

3. URL Reconstruction Vulnerability (MEDIUM PRIORITY)
In packages/next-js/src/mod.ts:20:

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

The all parameter from Next.js params is used directly without validation, potentially allowing path injection attacks.

Performance Concerns ⚡

1. Memory Buffering Issue (CRITICAL for Serverless)
packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:24-26:

// TODO: This buffers the entire request in memory every time. We
// need to properly implement streaming bodies.
const reqBody = await actorRequest.arrayBuffer();

This is particularly problematic in serverless environments with memory constraints and could cause cold start 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.

Security Concerns 🔒

1. Header Propagation Without Sanitization
packages/rivetkit/src/remote-manager-driver/actor-http-client.ts:61-63 - Headers are copied wholesale without validation, potentially allowing header injection attacks.

2. Missing Input Validation

No size limits on request bodies or parameters
Path segments in Next.js handler aren't validated
JSON parsing without error boundaries

Test Coverage 📊

Critical gaps:

No test files added for serverless functionality
The @rivetkit/next-js package lacks any test coverage
Missing integration tests for serverless workflow
No tests for error scenarios (malformed JSON, invalid paths)

Architecture & Design 🏗️

Positive aspects:

Clean separation with the new @rivetkit/next-js package
Proper use of disableServer: true and disableActorDriver: true flags
Good integration with existing RivetKit patterns
Versioned data handler is well-implemented with proper migration support

Technical Implementation Analysis:

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

Clean URL reconstruction but needs input validation
Comprehensive HTTP method support
Proper configuration flags for serverless mode

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

Robust data versioning with proper migration support
Good error handling for version mismatches
Clean separation of serialization concerns

scripts/nuke-cache.sh - Well-structured cache management:

Comprehensive coverage of JavaScript build cache directories
Good safety checks and colored output

Recommendations

Critical fixes needed before merge:

Implement endpoint access control for serverless mode - When serverlessActorDriverBuilder is present, disable or restrict access to non-essential endpoints
Add try-catch blocks around all JSON.parse() operations to prevent crashes
Address memory buffering TODO or implement request size limits for production use
Add input validation for path segments in Next.js handler

High priority improvements:

Add comprehensive test coverage for serverless functionality
Implement header validation and sanitization
Add request size limits to prevent DoS attacks
Complete remaining TODO items or create issues for future work

Medium priority:

Add JSDoc documentation for public APIs
Consider backward compatibility for Next.js versions
Implement dry-run mode for cache clearing script

Summary

This implementation provides solid serverless support for RivetKit with thoughtful architectural decisions. The core functionality is sound, but the critical issue identified in the review comment about endpoint access control must be addressed before merge. The versioned data handling and routing improvements are particularly well-implemented.

Overall Assessment: With the identified security and access control issues addressed, this will be a valuable addition to RivetKit's deployment options.

graphite-app · 2025-09-26T07:06:07Z

Merge activity

Sep 26, 7:06 AM UTC: NathanFlurry added this pull request to the Graphite merge queue.
Sep 26, 7:06 AM UTC: CI is running for this pull request on a draft pull request (#1312) due to your merge queue CI optimization settings.
Sep 26, 7:07 AM UTC: Merged by the Graphite merge queue via draft PR: #1312.

Fixes KIT-288

jog1t mentioned this pull request Sep 18, 2025

09-16-fix_next-js_fix_example_for_next-js #1250

Closed

This was referenced Sep 18, 2025

chore(core): fix test for sending message to specific connection sse race condition #1286

Closed

chore(core): fix missing transport for inline tests #1287

Closed

vercel bot had a problem deploying to Preview September 18, 2025 22:09 Failure

MasterPtato force-pushed the 09-18-feat_serverless branch from 9264aaf to 778f288 Compare September 19, 2025 18:26

MasterPtato marked this pull request as ready for review September 19, 2025 18:26

MasterPtato requested a review from NathanFlurry September 19, 2025 18:26

vercel bot had a problem deploying to Preview September 19, 2025 18:27 Failure

MasterPtato force-pushed the 09-18-feat_serverless branch from 778f288 to 173de9d Compare September 19, 2025 18:33

vercel bot deployed to Preview September 19, 2025 18:34 View deployment

MasterPtato force-pushed the 09-18-feat_serverless branch from 173de9d to 0dfc15e Compare September 19, 2025 19:24

vercel bot deployed to Preview September 19, 2025 19:25 View deployment

MasterPtato force-pushed the 09-18-feat_serverless branch from 0dfc15e to e86f95e Compare September 19, 2025 19:31

vercel bot deployed to Preview September 19, 2025 19:32 View deployment

MasterPtato force-pushed the 09-18-feat_serverless branch from e86f95e to 230e595 Compare September 19, 2025 20:08

vercel bot deployed to Preview September 19, 2025 20:09 View deployment

MasterPtato force-pushed the 09-18-feat_serverless branch from 230e595 to a1ed010 Compare September 19, 2025 21:19

vercel bot deployed to Preview September 19, 2025 21:20 View deployment

NathanFlurry suggested changes Sep 25, 2025

View reviewed changes

packages/rivetkit/src/manager/router.ts Outdated Show resolved Hide resolved

NathanFlurry force-pushed the 09-18-feat_serverless branch from a1ed010 to 8313206 Compare September 26, 2025 00:02

NathanFlurry force-pushed the 09-16-fix_next-js_fix_example_for_next-js branch from 49ed6fb to 1ba049d Compare September 26, 2025 00:02

This was referenced Sep 26, 2025

chore(core): add token & optional headers to client #1296

Closed

fix(core): fix missing ManagerDriver impls #1308

Closed

chore(core): clean up token configs #1298

Closed

fix(core): clean up websocket protocol handling #1297

Closed

vercel bot had a problem deploying to Preview September 26, 2025 00:20 Failure

feat: serverless

c313f20

NathanFlurry force-pushed the 09-18-feat_serverless branch from 8313206 to c313f20 Compare September 26, 2025 00:41

NathanFlurry force-pushed the 09-16-fix_next-js_fix_example_for_next-js branch from 1ba049d to 9749b77 Compare September 26, 2025 00:41

vercel bot had a problem deploying to Preview September 26, 2025 00:42 Failure

NathanFlurry approved these changes Sep 26, 2025

View reviewed changes

This was referenced Sep 26, 2025

chore(core): simplify connection handling & fix graceful reconnect #1309

Closed

chore(core): reimpl reconnect logic #1310

Closed

fix(core): fix getters on ActorConn proxy #1311

Closed

graphite-app bot pushed a commit that referenced this pull request Sep 26, 2025

feat: serverless (#1288)

58bdb8f

Fixes KIT-288

graphite-app bot closed this Sep 26, 2025

graphite-app bot deleted the 09-18-feat_serverless branch September 26, 2025 07:07

feat: serverless #1288

feat: serverless #1288

Uh oh!

Conversation

MasterPtato commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vercel bot commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

claude bot commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review: feat: serverless

Todo List:

Code Quality & Best Practices ✅

Potential Bugs & Issues 🔍

Performance Considerations ⚡

Security Concerns 🔒

Test Coverage 📊

Specific Technical Feedback

Summary

Uh oh!

MasterPtato commented Sep 18, 2025 • edited by NathanFlurry Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

How to use the Graphite Merge Queue

Uh oh!

pkg-pr-new bot commented Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

claude bot commented Sep 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review: feat: serverless

Todo List:

Overview

Code Quality & Best Practices ✅

Potential Bugs & Issues ⚠️

Performance Considerations ⚡

Security Concerns 🔒

Test Coverage 📊

Architecture & Design 🏗️

Specific Technical Feedback

Summary

Uh oh!

claude bot commented Sep 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review: feat: serverless

Todo List:

Overview

Code Quality & Best Practices ✅

Potential Bugs & Issues ⚠️

Performance Considerations ⚡

Security Concerns 🔒

Test Coverage 📊

Architecture & Design 🏗️

Summary

Uh oh!

claude bot commented Sep 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review: feat: serverless

Todo List:

Overview

Code Quality & Best Practices ✅

Potential Bugs & Issues ⚠️

Performance Considerations ⚡

Security Concerns 🔒

Test Coverage 📊

Architecture & Design 🏗️

Specific Technical Feedback

Summary

Uh oh!

claude bot commented Sep 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review: feat: serverless

Todo List:

Overview

Code Quality & Best Practices ✅

Potential Bugs & Issues ⚠️

Performance Considerations ⚡

Security Concerns 🔒

Test Coverage 📊

MasterPtato commented Sep 18, 2025 •

edited

Loading

vercel bot commented Sep 18, 2025 •

edited

Loading

claude bot commented Sep 18, 2025 •

edited

Loading

MasterPtato commented Sep 18, 2025 •

edited by NathanFlurry

Loading

pkg-pr-new bot commented Sep 18, 2025 •

edited

Loading

claude bot commented Sep 19, 2025 •

edited

Loading

claude bot commented Sep 19, 2025 •

edited

Loading

claude bot commented Sep 19, 2025 •

edited

Loading

claude bot commented Sep 19, 2025 •

edited

Loading

claude bot commented Sep 19, 2025 •

edited

Loading

claude bot commented Sep 19, 2025 •

edited

Loading

claude bot commented Sep 26, 2025 •

edited

Loading

claude bot commented Sep 26, 2025 •

edited

Loading