chore(core): simplify cors config

[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	Error			Sep 25, 2025 7:46am

[claude]

Claude finished @NathanFlurry's task —— View job

---

PR Review: Simplify CORS Config

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze the modified file (packages/rivetkit/src/manager/router.ts)
• Check for related test files and CORS usage patterns
• Review for code quality, bugs, performance, and security issues
• Provide comprehensive feedback

Review Findings

This PR simplifies the CORS middleware configuration in the manager router by removing unnecessary middleware composition and route-specific CORS declarations. Here's my analysis:

✅ Code Quality & Best Practices

Positive Changes:

• Simplified Logic: The change from conditionally creating a CORS middleware vs noop middleware to a simple conditional application is cleaner and more readable
• Reduced Complexity: Eliminates unnecessary middleware composition with the cors variable
• Consistent Pattern: Now matches the pattern used in the actor router (packages/rivetkit/src/actor/router.ts:250)

Before:

const cors = runConfig.cors
  ? corsMiddleware(runConfig.cors)
  : createMiddleware((_c, next) => next());

After:

if (runConfig.cors) {
  router.use("*", corsMiddleware(runConfig.cors));
}

✅ Functionality & Behavior

Preserved Behavior:

• CORS is still applied globally via router.use("*", ...) when configured
• All routes inherit CORS settings through Hono's middleware chain
• The conditional application ensures no CORS middleware when runConfig.cors is undefined/falsy

Removed Redundancy:

• Route-specific CORS middleware declarations were redundant since global middleware already applies
• Inspector route now properly inherits from global CORS instead of having its own configuration

⚠️ Potential Considerations

1. Inspector CORS Configuration: The change removes the specific CORS configuration for the inspector route:

   - .use(corsMiddleware(runConfig.inspector.cors))
   

   Impact: The inspector now uses the global runConfig.cors instead of runConfig.inspector.cors. This could be:

   • Intentional: Simplifying to use one CORS config across all routes
   • Unintentional: The inspector might need its own CORS settings

   Location: packages/rivetkit/src/manager/router.ts:442

2. Configuration Backwards Compatibility: Verify that consumers expecting separate inspector CORS config are updated accordingly.

🔍 Security Analysis

• No Security Regression: The CORS functionality remains intact with global application
• Origin Validation: CORS origin validation still works through the global middleware
• Inspector Security: Inspector maintains its security through secureInspector(runConfig) middleware

🚀 Performance Benefits

• Reduced Middleware Stack: Eliminates redundant middleware layers on individual routes
• Memory Efficiency: No longer creates unnecessary noop middleware instances
• Execution Path: Cleaner execution with fewer conditional middleware evaluations

📋 Missing Elements

1. Test Coverage: No tests found for CORS functionality. Consider adding tests for:

   • CORS header presence/absence based on runConfig.cors configuration
   • Inspector route CORS behavior after this change

2. Breaking Change Documentation: If inspector CORS behavior changes, this should be documented as a potential breaking change.

Recommendation

The change looks good overall and simplifies the CORS configuration appropriately. However, I recommend:

1. Verify Inspector CORS Intent: Confirm whether the inspector should use global CORS or needs separate configuration
2. Add Tests: Consider adding basic CORS functionality tests to prevent regressions
3. Update Documentation: If inspector CORS behavior changed, document it for users

The code quality improvement and pattern consistency make this a positive change.

---

[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): simplify cors config #1299 👈 (View in Graphite)
• chore(example): update chat example #1301 : 1 other dependent PR (#1302 )
• fix(core): fix passing incorrect actor input to create #1300
• fix(inspector): allow connection to inspector when using engine driver #1269
• main

---

How to use the Graphite Merge Queue

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

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

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[pkg-pr-new]

More templates

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

@rivetkit/actor

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

@rivetkit/cloudflare-workers

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

@rivetkit/core

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

@rivetkit/db

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

@rivetkit/framework-base

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

@rivetkit/next-js

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

@rivetkit/react

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

rivetkit

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

@rivetkit/sql-loader

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

commit: e5e91b7

[claude]

Claude finished @NathanFlurry's task —— View job

---

PR Review: Simplify CORS Config

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze the modified file (packages/rivetkit/src/manager/router.ts)
• Check for related test files and CORS usage patterns
• Review for code quality, bugs, performance, and security issues
• Provide comprehensive feedback

Review Findings

This PR simplifies the CORS middleware configuration in the manager router by removing unnecessary middleware composition and route-specific CORS declarations. Here's my analysis:

✅ Code Quality & Best Practices

Positive Changes:

• Simplified Logic: The change from conditionally creating a CORS middleware vs noop middleware to a simple conditional application is cleaner and more readable
• Reduced Complexity: Eliminates unnecessary middleware composition with the cors variable
• Consistent Pattern: Now matches the pattern used in the actor router (packages/rivetkit/src/actor/router.ts:250)

Before:

const cors = runConfig.cors
  ? corsMiddleware(runConfig.cors)
  : createMiddleware((_c, next) => next());

After:

if (runConfig.cors) {
  router.use("*", corsMiddleware(runConfig.cors));
}

✅ Functionality & Behavior

Preserved Behavior:

• CORS is still applied globally via router.use("*", ...) when configured
• All routes inherit CORS settings through Hono's middleware chain
• The conditional application ensures no CORS middleware when runConfig.cors is undefined/falsy

Removed Redundancy:

• Route-specific CORS middleware declarations were redundant since global middleware already applies
• Inspector route now properly inherits from global CORS instead of having its own configuration

⚠️ Potential Considerations

1. Inspector CORS Configuration: The change removes the specific CORS configuration for the inspector route:

   - .use(corsMiddleware(runConfig.inspector.cors))

   Impact: The inspector now uses the global runConfig.cors instead of runConfig.inspector.cors. This could be:

   • Intentional: Simplifying to use one CORS config across all routes
   • Unintentional: The inspector might need its own CORS settings

   Location: packages/rivetkit/src/manager/router.ts:442

2. Configuration Backwards Compatibility: Verify that consumers expecting separate inspector CORS config are updated accordingly.

🔍 Security Analysis

• No Security Regression: The CORS functionality remains intact with global application
• Origin Validation: CORS origin validation still works through the global middleware
• Inspector Security: Inspector maintains its security through secureInspector(runConfig) middleware

🚀 Performance Benefits

• Reduced Middleware Stack: Eliminates redundant middleware layers on individual routes
• Memory Efficiency: No longer creates unnecessary noop middleware instances
• Execution Path: Cleaner execution with fewer conditional middleware evaluations

📋 Missing Elements

1. Test Coverage: No tests found for CORS functionality. Consider adding tests for:

   • CORS header presence/absence based on runConfig.cors configuration
   • Inspector route CORS behavior after this change

2. Breaking Change Documentation: If inspector CORS behavior changes, this should be documented as a potential breaking change.

Recommendation

The change looks good overall and simplifies the CORS configuration appropriately. However, I recommend:

1. Verify Inspector CORS Intent: Confirm whether the inspector should use global CORS or needs separate configuration
2. Add Tests: Consider adding basic CORS functionality tests to prevent regressions
3. Update Documentation: If inspector CORS behavior changed, document it for users

The code quality improvement and pattern consistency make this a positive change.

---

[claude]

Claude finished @NathanFlurry's task —— View job

---

PR Review: Simplify CORS Config

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze the modified file (packages/rivetkit/src/manager/router.ts)
• Check for related test files and CORS usage patterns
• Review for code quality, bugs, performance, and security issues
• Provide comprehensive feedback

Review Findings

This PR simplifies the CORS middleware configuration in the manager router by removing unnecessary middleware composition and route-specific CORS declarations. Here's my analysis:

✅ Code Quality & Best Practices

Positive Changes:

• Simplified Logic: The change from conditionally creating a CORS middleware vs noop middleware to a simple conditional application is cleaner and more readable
• Reduced Complexity: Eliminates unnecessary middleware composition with the cors variable
• Consistent Pattern: Now matches the pattern used in the actor router (packages/rivetkit/src/actor/router.ts:250)

Before:

const cors = runConfig.cors
  ? corsMiddleware(runConfig.cors)
  : createMiddleware((_c, next) => next());

After:

if (runConfig.cors) {
  router.use("*", corsMiddleware(runConfig.cors));
}

✅ Functionality & Behavior

Preserved Behavior:

• CORS is still applied globally via router.use("*", ...) when configured
• All routes inherit CORS settings through Hono's middleware chain
• The conditional application ensures no CORS middleware when runConfig.cors is undefined/falsy

Removed Redundancy:

• Route-specific CORS middleware declarations were redundant since global middleware already applies
• Inspector route now properly inherits from global CORS instead of having its own configuration

⚠️ Potential Considerations

1. Inspector CORS Configuration: The change removes the specific CORS configuration for the inspector route:

   - .use(corsMiddleware(runConfig.inspector.cors))

   Impact: The inspector now uses the global runConfig.cors instead of runConfig.inspector.cors. This could be:

   • Intentional: Simplifying to use one CORS config across all routes
   • Unintentional: The inspector might need its own CORS settings

   Location: packages/rivetkit/src/manager/router.ts:442

2. Configuration Backwards Compatibility: Verify that consumers expecting separate inspector CORS config are updated accordingly.

🔍 Security Analysis

• No Security Regression: The CORS functionality remains intact with global application
• Origin Validation: CORS origin validation still works through the global middleware
• Inspector Security: Inspector maintains its security through secureInspector(runConfig) middleware

🚀 Performance Benefits

• Reduced Middleware Stack: Eliminates redundant middleware layers on individual routes
• Memory Efficiency: No longer creates unnecessary noop middleware instances
• Execution Path: Cleaner execution with fewer conditional middleware evaluations

📋 Missing Elements

1. Test Coverage: No tests found for CORS functionality. Consider adding tests for:

   • CORS header presence/absence based on runConfig.cors configuration
   • Inspector route CORS behavior after this change

2. Breaking Change Documentation: If inspector CORS behavior changes, this should be documented as a potential breaking change.

Recommendation

The change looks good overall and simplifies the CORS configuration appropriately. However, I recommend:

1. Verify Inspector CORS Intent: Confirm whether the inspector should use global CORS or needs separate configuration
2. Add Tests: Consider adding basic CORS functionality tests to prevent regressions
3. Update Documentation: If inspector CORS behavior changed, document it for users

The code quality improvement and pattern consistency make this a positive change.

---