chore(core): kitchen sink example

[NathanFlurry]

No description provided.

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
rivetkit-serverless	Ready	Preview	Comment	Oct 2, 2025 8:47pm

[claude]

Claude finished @NathanFlurry's task —— View job

---

Code Review for Kitchen Sink Example

Reviewing this PR that adds a comprehensive kitchen sink example to demonstrate RivetKit features.

Todo List:

• Read project guidelines from CLAUDE.md
• Review kitchen sink example structure and README
• Examine backend actor implementations (demo, http, websocket)
• Review frontend React components and architecture
• Check core rivetkit modifications for breaking changes
• Assess package.json and dependencies
• Evaluate code quality, security, and performance
• Provide comprehensive feedback

---

✅ Positive Aspects

1. Comprehensive Example: This is an excellent kitchen sink example that demonstrates most RivetKit features including actions, events, scheduling, state management, HTTP/WebSocket handling, and React integration.

2. Good Project Structure: Follows the established project conventions from CLAUDE.md, including proper package naming (example-kitchen-sink), workspace dependencies, and README format.

3. Educational Value: The example covers a wide range of use cases that would be valuable for developers learning RivetKit.

4. Proper Logging: Uses structured logging consistently throughout the codebase.

---

🔧 Issues to Address

Critical Issues

1. Type Safety Violations (examples/kitchen-sink/src/backend/actors/http.ts:4, websocket.ts:4)

   export function handleHttpRequest(
     c: ActorContext<any, any, any, any, any, any>, // ❌ Using 'any' types

   This violates the CLAUDE.md guideline: "Don't try to fix type issues by casting to unknown or any." The functions should use proper generic constraints or specific types.

2. Unsafe JSON Parsing (examples/kitchen-sink/src/frontend/App.tsx:56, App.tsx:67)

   const createInput = state.createInput ? JSON.parse(state.createInput) : undefined; // ❌ No error handling

   This could throw runtime errors if invalid JSON is provided.

Security Concerns

3. Unsafe State Mutation (websocket.ts:8)

   const connectionId = `conn-${Date.now()}-${Math.random().toString(36).substr(2, 9)}`;

   Uses deprecated substr() method and weak randomness. Should use substring() and crypto.randomUUID() for better security.

4. Unrestricted State Access (Multiple files)
   The actors directly mutate state without validation, which could lead to state corruption if malicious input is provided.

Performance Issues

5. Memory Leaks (demo.ts:9, http.ts:13-21, websocket.ts:12-36)

   alarmHistory: [] as { id: string; time: number; data?: any }[],
   requestHistory: [],
   messageHistory: [],

   These arrays grow indefinitely without cleanup, potentially causing memory leaks in long-running actors.

6. Inefficient Array Operations (websocket.ts:183)

   messageHistory: (c.state.messageHistory || []).slice(-50), // Creates new array every time

Code Quality Issues

7. Missing Error Handling (websocket.ts:127)

   } catch {
     // If not JSON, just echo it back - No error logging
   }

8. Magic Numbers (demo.ts:143)

   sleepTimeout: 2000, // Should be a named constant

9. Inconsistent Naming (demo.ts:123)

   broadcastCustomEvent: (c, eventName: string, data: any) => {

   Should follow camelCase consistently.

Documentation Issues

10. Missing JSDoc Comments: Public actions lack proper documentation, violating CLAUDE.md guidelines for public APIs.

11. Incomplete README: The README doesn't explain what features are being demonstrated or how to test them.

---

📊 Core RivetKit Changes Review

Good Changes

1. Better Logging Level (instance.ts:431): Changed warning to debug for normal operation scenario.

2. CORS Fix (router.ts:214-254): Properly applies CORS middleware to raw HTTP endpoints, fixing potential CORS issues.

3. Configuration Enhancement (run-config.ts:57-65): Adds configurable port with sensible defaults.

Potential Issues

4. Breaking Change Risk: The router changes modify how raw HTTP endpoints are handled. This should be documented as potentially breaking.

---

🧪 Test Coverage

Missing: No tests are included for the kitchen sink example. While examples don't always need comprehensive tests, at least basic functionality tests would be valuable.

---

📝 Recommendations

High Priority

1. Fix type safety violations by properly typing the actor context parameters
2. Add proper error handling for JSON parsing operations
3. Implement bounds checking for history arrays to prevent memory leaks
4. Replace deprecated substr() with substring() and use secure random generation

Medium Priority

5. Add JSDoc comments for all public actions
6. Implement proper error logging in catch blocks
7. Extract magic numbers to named constants
8. Add basic smoke tests for the example

Low Priority

9. Enhance README with feature explanations and testing instructions
10. Consider adding TypeScript strict mode to catch more issues

---

🏁 Summary

This is a valuable addition to the project that will help developers understand RivetKit's capabilities. However, it needs several improvements around type safety, error handling, and performance before merging. The core RivetKit changes look good and address real issues.

Recommendation: Request changes for critical type safety and security issues before approval.

---

[NathanFlurry]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• chore(core): kitchen sink example #1328 👈 (View in Graphite)
• chore(core): tweak schedule logging #1332
• fix(core): fix encoding input for remote manager driver #1331
• 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-kitchen-sink
• example-next-js
• example-rate
• example-raw-fetch-handler
• example-raw-websocket-handler-proxy
• example-react
• starter
• example-stream
• example-sync
• example-tenant
• example-trpc

@rivetkit/actor

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

@rivetkit/cloudflare-workers

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

@rivetkit/core

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

@rivetkit/db

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

@rivetkit/framework-base

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

@rivetkit/next-js

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

@rivetkit/react

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

rivetkit

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

@rivetkit/sql-loader

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

commit: faee9b1

[claude]

Claude finished @NathanFlurry's task —— View job

---

Reviewing Kitchen Sink Example PR

Code Review Progress

• Read CLAUDE.md for project guidelines
• Review kitchen sink example structure and README
• Examine backend actor implementations (demo, http, websocket)
• Review frontend React components and architecture
• Check core rivetkit modifications for breaking changes
• Assess package.json and dependencies
• Evaluate code quality, security, and performance
• Provide comprehensive feedback

---

✅ Positive Aspects

1. Comprehensive Example: This is an excellent kitchen sink example that demonstrates most RivetKit features including actions, events, scheduling, state management, HTTP/WebSocket handling, and React integration.

2. Good Project Structure: Follows the established project conventions from CLAUDE.md:

   • Proper package naming (example-kitchen-sink)
   • Uses workspace:* dependencies
   • Follows README structure guidelines
   • Includes required turbo.json configuration

3. Educational Value: The example covers a wide range of use cases that would be valuable for developers learning RivetKit.

4. Proper Logging: Uses structured logging consistently throughout the codebase with c.log.info().

---

🔧 Critical Issues to Address

Type Safety Violations

1. Using any types (examples/kitchen-sink/src/backend/actors/http.ts:4, websocket.ts:4-6)

   export function handleHttpRequest(
     c: ActorContext<any, any, any, any, any, any>, // ❌ Using 'any' types

   This violates CLAUDE.md guideline: "Don't try to fix type issues by casting to unknown or any." The functions should use proper generic constraints or specific types.

2. Unsafe JSON Parsing (examples/kitchen-sink/src/frontend/App.tsx:71, App.tsx:82)

   const createInput = state.createInput ? JSON.parse(state.createInput) : undefined; // ❌ No error handling

   This could throw runtime errors if invalid JSON is provided.

Security Concerns

3. Deprecated and Weak Randomness (websocket.ts:8)

   const connectionId = `conn-${Date.now()}-${Math.random().toString(36).substr(2, 9)}`;

   • Uses deprecated substr() method (should use substring())
   • Uses weak Math.random() for IDs (should use crypto.randomUUID())

4. Missing Error Handling (websocket.ts:127)

   } catch {
     // If not JSON, just echo it back - No error logging
   }

Performance Issues

5. Memory Leaks - Unbounded Arrays (demo.ts:10, http.ts:13-21, websocket.ts:12-36)

   alarmHistory: [] as { id: string; time: number; data?: any }[],
   requestHistory: [],
   messageHistory: [],

   These arrays grow indefinitely without cleanup, potentially causing memory leaks in long-running actors.

6. Inefficient Array Operations (websocket.ts:183)

   messageHistory: (c.state.messageHistory || []).slice(-50), // Creates new array every time

Code Quality Issues

7. Magic Numbers (demo.ts:153)

   sleepTimeout: 2000, // Should be a named constant

8. Missing JSDoc Comments: Public actions lack proper documentation, violating CLAUDE.md guidelines for public APIs.

9. Inconsistent Error Handling: Some areas have proper try-catch blocks while others silently fail.

---

📊 Repository Guidelines Compliance

✅ Follows Guidelines

• Package naming convention (example-kitchen-sink)
• Uses workspace:* for dependencies
• Includes dev and check-types scripts
• README follows required structure
• Uses tsx for TypeScript execution
• Proper turbo.json configuration

❌ Violates Guidelines

• Type safety violations with any usage
• Missing JSDoc for public APIs
• Not using proper error classes from ActorError base

---

🧪 Test Coverage

Missing: No tests are included for the kitchen sink example. While examples don't always need comprehensive tests, at least basic functionality tests would be valuable for such a comprehensive example.

---

📝 Recommendations

High Priority (Must Fix)

1. Fix type safety: Replace any types with proper generic constraints or specific interfaces
2. Add error handling: Wrap JSON parsing in try-catch blocks
3. Security fixes: Replace substr() with substring() and use crypto.randomUUID()
4. Memory management: Implement bounds checking for history arrays (limit size, implement cleanup)

Medium Priority

5. Add JSDoc comments: Document all public actions and methods
6. Error logging: Add proper error logging in catch blocks
7. Extract constants: Replace magic numbers with named constants
8. Consistent error handling: Use ActorError-based classes throughout

Low Priority

9. Add basic tests: At least smoke tests for the example
10. Performance optimization: Consider more efficient data structures for frequently accessed arrays

---

🏁 Summary

This is a valuable addition that demonstrates RivetKit's comprehensive feature set. However, it needs several critical fixes around type safety, security, and memory management before merging. The violations of CLAUDE.md guidelines (particularly around type safety) need to be addressed to maintain code quality standards.

Recommendation: Request changes for critical type safety and security issues before approval.

---

[claude]

Claude finished @NathanFlurry's task —— View job

---

Code Review for Kitchen Sink Example

Reviewing this PR that adds a comprehensive kitchen sink example to demonstrate RivetKit features.

Todo List:

• Read project guidelines from CLAUDE.md
• Review kitchen sink example structure and README
• Examine backend actor implementations (demo, http, websocket)
• Review frontend React components and architecture
• Check core rivetkit modifications for breaking changes
• Assess package.json and dependencies
• Evaluate code quality, security, and performance
• Provide comprehensive feedback

---

✅ Positive Aspects

1. Comprehensive Example: This is an excellent kitchen sink example that demonstrates most RivetKit features including actions, events, scheduling, state management, HTTP/WebSocket handling, and React integration.

2. Good Project Structure: Follows the established project conventions from CLAUDE.md, including proper package naming (example-kitchen-sink), workspace dependencies, and README format.

3. Educational Value: The example covers a wide range of use cases that would be valuable for developers learning RivetKit.

4. Proper Logging: Uses structured logging consistently throughout the codebase.

---

🔧 Issues to Address

Critical Issues

1. Type Safety Violations (examples/kitchen-sink/src/backend/actors/http.ts:4, websocket.ts:4)

   export function handleHttpRequest(
     c: ActorContext<any, any, any, any, any, any>, // ❌ Using 'any' types

   This violates the CLAUDE.md guideline: "Don't try to fix type issues by casting to unknown or any." The functions should use proper generic constraints or specific types.

2. Unsafe JSON Parsing (examples/kitchen-sink/src/frontend/App.tsx:71, App.tsx:82)

   const createInput = state.createInput ? JSON.parse(state.createInput) : undefined; // ❌ No error handling

   This could throw runtime errors if invalid JSON is provided.

Security Concerns

3. Unsafe State Mutation (websocket.ts:8)

   const connectionId = `conn-${Date.now()}-${Math.random().toString(36).substr(2, 9)}`;

   Uses deprecated substr() method and weak randomness. Should use substring() and crypto.randomUUID() for better security.

4. Unrestricted State Access (Multiple files)
   The actors directly mutate state without validation, which could lead to state corruption if malicious input is provided.

Performance Issues

5. Memory Leaks (demo.ts:10, http.ts:13-21, websocket.ts:12-36)

   alarmHistory: [] as { id: string; time: number; data?: any }[],
   requestHistory: [],
   messageHistory: [],

   These arrays grow indefinitely without cleanup, potentially causing memory leaks in long-running actors.

6. Inefficient Array Operations (websocket.ts:183)

   messageHistory: (c.state.messageHistory || []).slice(-50), // Creates new array every time

Code Quality Issues

7. Missing Error Handling (websocket.ts:127)

   } catch {
     // If not JSON, just echo it back - No error logging
   }

8. Magic Numbers (demo.ts:153)

   sleepTimeout: 2000, // Should be a named constant

9. Inconsistent Naming (demo.ts:133)

   broadcastCustomEvent: (c, eventName: string, data: any) => {

   Should follow camelCase consistently.

Documentation Issues

10. Missing JSDoc Comments: Public actions lack proper documentation, violating CLAUDE.md guidelines for public APIs.

11. Incomplete README: The README doesn't explain what features are being demonstrated or how to test them.

---

📊 Core RivetKit Changes Review

Good News: This PR only adds example code - no core rivetkit modifications were made. This reduces the risk of breaking changes to the library itself.

---

🧪 Test Coverage

Missing: No tests are included for the kitchen sink example. While examples don't always need comprehensive tests, at least basic functionality tests would be valuable.

---

📝 Recommendations

High Priority

1. Fix type safety violations by properly typing the actor context parameters
2. Add proper error handling for JSON parsing operations
3. Implement bounds checking for history arrays to prevent memory leaks
4. Replace deprecated substr() with substring() and use secure random generation

Medium Priority

5. Add JSDoc comments for all public actions
6. Implement proper error logging in catch blocks
7. Extract magic numbers to named constants
8. Add basic smoke tests for the example

Low Priority

9. Enhance README with feature explanations and testing instructions
10. Consider adding TypeScript strict mode to catch more issues

---

🏁 Summary

This is a valuable addition to the project that will help developers understand RivetKit's capabilities. However, it needs several improvements around type safety, error handling, and performance before merging.

Recommendation: Request changes for critical type safety and security issues before approval.

---

[claude]

Claude finished @NathanFlurry's task —— View job

---

Comprehensive Code Review: Kitchen Sink Example

Code Review Progress

• Read CLAUDE.md for project guidelines
• Review kitchen sink example structure and README
• Examine backend actor implementations (demo, http, websocket)
• Review frontend React components and architecture
• Check core rivetkit modifications for breaking changes
• Assess package.json and dependencies
• Evaluate code quality, security, and performance
• Provide comprehensive feedback

---

📊 Overview

This PR adds a comprehensive kitchen sink example demonstrating RivetKit features. The example includes backend actors, React frontend, and covers actions, events, scheduling, HTTP/WebSocket handling, and multiple transport/encoding options.

---

✅ Positive Aspects

1. Comprehensive Feature Coverage

• Demonstrates most RivetKit features: actions, events, scheduling, state management, HTTP/WebSocket handling
• Good educational value for developers learning RivetKit
• Well-structured example with clear separation of concerns

2. Follows Project Conventions

• Package naming follows CLAUDE.md guidelines (example-kitchen-sink)
• Uses workspace dependencies correctly
• README follows the required structure
• Includes proper turbo.json configuration

3. React Integration

• Good use of @rivetkit/react package
• Proper state management with hooks
• Configurable transport and encoding options

---

🚨 Critical Issues

1. Type Safety Violations

Location: examples/kitchen-sink/src/backend/actors/http.ts:4, websocket.ts:4

export function handleHttpRequest(
  c: ActorContext<any, any, any, any, any, any>, // ❌ Using 'any' types

Issue: Violates CLAUDE.md guideline: "Don't try to fix type issues by casting to unknown or any."
Impact: Loss of type safety, potential runtime errors
Recommendation: Use proper generic constraints or specific actor context types

2. Unsafe JSON Parsing

Location: examples/kitchen-sink/src/frontend/App.tsx:71,82

const createInput = state.createInput ? JSON.parse(state.createInput) : undefined; // ❌ No error handling

Issue: Could throw runtime errors with invalid JSON
Impact: Application crashes with malformed input
Recommendation: Add try-catch blocks with user-friendly error messages

3. Security Vulnerability - Weak Random Generation

Location: examples/kitchen-sink/src/backend/actors/websocket.ts:8

const connectionId = `conn-${Date.now()}-${Math.random().toString(36).substr(2, 9)}`;

Issues:

• Uses deprecated substr() method
• Math.random() is not cryptographically secure
• Predictable connection IDs could lead to security issues
  Recommendation: Use crypto.randomUUID() and substring()

---

⚠️ Performance Issues

4. Memory Leaks - Unbounded Array Growth

Locations:

• demo.ts:10 - alarmHistory: [] as { id: string; time: number; data?: any }[]
• http.ts:13-21 - requestHistory: []
• websocket.ts:12-36 - messageHistory: []

Issue: Arrays grow indefinitely without cleanup
Impact: Memory exhaustion in long-running actors
Recommendation: Implement size limits and cleanup strategies:

// Example fix
c.state.alarmHistory.push(alarmEntry);
if (c.state.alarmHistory.length > 1000) {
  c.state.alarmHistory = c.state.alarmHistory.slice(-500);
}

5. Inefficient Array Operations

Location: websocket.ts:183

messageHistory: (c.state.messageHistory || []).slice(-50), // Creates new array every time

Issue: Creates new array on every call instead of implementing proper pagination
Recommendation: Implement proper pagination or use more efficient data structures

---

🔧 Code Quality Issues

6. Missing Error Handling

Location: websocket.ts:127

} catch {
  // If not JSON, just echo it back - No error logging
}

Issue: Silent error handling without logging violates CLAUDE.md logging guidelines
Recommendation: Add proper error logging using c.log.warn()

7. Magic Numbers

Location: demo.ts:153

sleepTimeout: 2000, // Should be a named constant

Issue: Magic numbers reduce code maintainability
Recommendation: Extract to named constants

8. Inconsistent Naming

Location: demo.ts:133

broadcastCustomEvent: (c, eventName: string, data: any) => {

Issue: Should follow camelCase consistently per CLAUDE.md guidelines

9. Missing JSDoc Comments

Issue: Public actions lack proper documentation
Impact: Violates CLAUDE.md guidelines for public APIs
Recommendation: Add comprehensive JSDoc comments for all public actions

---

🧪 Test Coverage

10. No Test Coverage

Issue: No tests included for the kitchen sink example
Impact: No verification of functionality, potential for regressions
Recommendation: Add basic smoke tests to verify core functionality

---

📦 Dependencies & Configuration

✅ Package.json

• Correct naming convention
• Proper workspace dependencies
• Appropriate scripts (dev, check-types)
• Good use of concurrently for development

✅ No Core Breaking Changes

• No modifications to core RivetKit packages detected
• This is purely an example addition

---

🛡️ Security Assessment

Medium Risk Issues:

1. Weak Connection ID Generation - Predictable IDs could be exploited
2. Unrestricted State Mutation - No input validation on state changes
3. JSON Parsing without Validation - Could lead to prototype pollution

Recommendations:

• Use crypto.randomUUID() for secure ID generation
• Add input validation for all user-provided data
• Implement JSON schema validation for parsed inputs

---

📝 Recommendations

High Priority (Must Fix)

1. ✅ Replace any types with proper type constraints
2. ✅ Add error handling for JSON parsing operations
3. ✅ Fix memory leak issues with bounded arrays
4. ✅ Replace deprecated substr() and use secure random generation

Medium Priority (Should Fix)

5. Add comprehensive JSDoc comments for public APIs
6. Implement proper error logging in catch blocks
7. Extract magic numbers to named constants
8. Add input validation for user data

Low Priority (Nice to Have)

9. Add basic test coverage
10. Enhance README with feature explanations and testing instructions
11. Consider adding TypeScript strict mode

---

🏁 Overall Assessment

Strengths: Excellent educational example that demonstrates RivetKit's capabilities comprehensively. Good project structure and follows most conventions.

Concerns: Several critical type safety, security, and performance issues that should be addressed before merging. The example could mislead developers into using unsafe patterns.

Recommendation: Request Changes - Address the critical type safety, security, and performance issues before approval. This will ensure the example serves as a good reference implementation.

Impact: High value addition to the project once issues are resolved. Will significantly help developers understand RivetKit's capabilities.

---

[claude]

Claude finished @NathanFlurry's task —— View job

---

Comprehensive Code Review: Kitchen Sink Example

Review Progress

• Read project guidelines from CLAUDE.md
• Review kitchen sink example structure and README
• Examine backend actor implementations (demo, http, websocket)
• Review frontend React components and architecture
• Check core rivetkit modifications for breaking changes
• Assess package.json and dependencies
• Evaluate code quality, security, and performance
• Provide comprehensive feedback

---

📊 Overview

This PR adds a comprehensive kitchen sink example demonstrating RivetKit features. The example includes backend actors, React frontend, and covers actions, events, scheduling, HTTP/WebSocket handling, and multiple transport/encoding options.

---

✅ Positive Aspects

1. Comprehensive Feature Coverage

• Demonstrates most RivetKit features: actions, events, scheduling, state management, HTTP/WebSocket handling
• Good educational value for developers learning RivetKit
• Well-structured example with clear separation of concerns

2. Follows Project Conventions

• Package naming follows CLAUDE.md guidelines (example-kitchen-sink)
• Uses workspace dependencies correctly
• README follows the required structure
• Includes proper turbo.json configuration

3. React Integration

• Good use of @rivetkit/react package
• Proper state management with hooks
• Configurable transport and encoding options

---

🚨 Critical Issues

1. Type Safety Violations

Location: examples/kitchen-sink/src/backend/actors/http.ts:4, websocket.ts:4

export function handleHttpRequest(
  c: ActorContext<any, any, any, any, any, any>, // ❌ Using 'any' types

Issue: Violates CLAUDE.md guideline: "Don't try to fix type issues by casting to unknown or any."
Impact: Loss of type safety, potential runtime errors
Recommendation: Use proper generic constraints or specific actor context types

2. Unsafe JSON Parsing

Location: examples/kitchen-sink/src/frontend/App.tsx:71,82

const createInput = state.createInput ? JSON.parse(state.createInput) : undefined; // ❌ No error handling

Issue: Could throw runtime errors with invalid JSON
Impact: Application crashes with malformed input
Recommendation: Add try-catch blocks with user-friendly error messages

3. Security Vulnerability - Weak Random Generation

Location: examples/kitchen-sink/src/backend/actors/websocket.ts:8

const connectionId = `conn-${Date.now()}-${Math.random().toString(36).substr(2, 9)}`;

Issues:

• Uses deprecated substr() method
• Math.random() is not cryptographically secure
• Predictable connection IDs could lead to security issues
  Recommendation: Use crypto.randomUUID() and substring()

---

⚠️ Performance Issues

4. Memory Leaks - Unbounded Array Growth

Locations:

• demo.ts:10 - alarmHistory: [] as { id: string; time: number; data?: any }[]
• http.ts:13-21 - requestHistory: []
• websocket.ts:12-36 - messageHistory: []

Issue: Arrays grow indefinitely without cleanup
Impact: Memory exhaustion in long-running actors
Recommendation: Implement size limits and cleanup strategies:

// Example fix
c.state.alarmHistory.push(alarmEntry);
if (c.state.alarmHistory.length > 1000) {
  c.state.alarmHistory = c.state.alarmHistory.slice(-500);
}

5. Inefficient Array Operations

Location: websocket.ts:183

messageHistory: (c.state.messageHistory || []).slice(-50), // Creates new array every time

Issue: Creates new array on every call instead of implementing proper pagination
Recommendation: Implement proper pagination or use more efficient data structures

---

🔧 Code Quality Issues

6. Missing Error Handling

Location: websocket.ts:127

} catch {
  // If not JSON, just echo it back - No error logging
}

Issue: Silent error handling without logging violates CLAUDE.md logging guidelines
Recommendation: Add proper error logging using c.log.warn()

7. Magic Numbers

Location: demo.ts:153

sleepTimeout: 2000, // Should be a named constant

Issue: Magic numbers reduce code maintainability
Recommendation: Extract to named constants

8. Inconsistent Naming

Location: demo.ts:133

broadcastCustomEvent: (c, eventName: string, data: any) => {

Issue: Should follow camelCase consistently per CLAUDE.md guidelines

9. Missing JSDoc Comments

Issue: Public actions lack proper documentation
Impact: Violates CLAUDE.md guidelines for public APIs
Recommendation: Add comprehensive JSDoc comments for all public actions

---

🧪 Test Coverage

10. No Test Coverage

Issue: No tests included for the kitchen sink example
Impact: No verification of functionality, potential for regressions
Recommendation: Add basic smoke tests to verify core functionality

---

📦 Dependencies & Configuration

✅ Package.json

• Correct naming convention
• Proper workspace dependencies
• Appropriate scripts (dev, check-types)
• Good use of concurrently for development

✅ No Core Breaking Changes

• No modifications to core RivetKit packages detected
• This is purely an example addition

---

🛡️ Security Assessment

Medium Risk Issues:

1. Weak Connection ID Generation - Predictable IDs could be exploited
2. Unrestricted State Mutation - No input validation on state changes
3. JSON Parsing without Validation - Could lead to prototype pollution

Recommendations:

• Use crypto.randomUUID() for secure ID generation
• Add input validation for all user-provided data
• Implement JSON schema validation for parsed inputs

---

📝 Recommendations

High Priority (Must Fix)

1. ✅ Replace any types with proper type constraints
2. ✅ Add error handling for JSON parsing operations
3. ✅ Fix memory leak issues with bounded arrays
4. ✅ Replace deprecated substr() and use secure random generation

Medium Priority (Should Fix)

5. Add comprehensive JSDoc comments for public APIs
6. Implement proper error logging in catch blocks
7. Extract magic numbers to named constants
8. Add input validation for user data

Low Priority (Nice to Have)

9. Add basic test coverage
10. Enhance README with feature explanations and testing instructions
11. Consider adding TypeScript strict mode

---

🏁 Overall Assessment

Strengths: Excellent educational example that demonstrates RivetKit's capabilities comprehensively. Good project structure and follows most conventions.

Concerns: Several critical type safety, security, and performance issues that should be addressed before merging. The example could mislead developers into using unsafe patterns.

Recommendation: Request Changes - Address the critical type safety, security, and performance issues before approval. This will ensure the example serves as a good reference implementation.

Impact: High value addition to the project once issues are resolved. Will significantly help developers understand RivetKit's capabilities.

---

[graphite-app]

Merge activity

• Oct 2, 8:47 PM UTC: NathanFlurry added this pull request to the Graphite merge queue.
• Oct 2, 8:47 PM UTC: CI is running for this pull request on a draft pull request (#1333) due to your merge queue CI optimization settings.
• Oct 2, 8:48 PM UTC: Merged by the Graphite merge queue via draft PR: #1333.