chore(cloudflare-workers): upgrade to new manager api

[NathanFlurry]

No description provided.

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
rivetkit-express	Error			Sep 16, 2025 11:20pm

[claude]

Claude finished @NathanFlurry's task —— View job

---

Code Review for Cloudflare Workers Manager API Upgrade

Reviewing the pull request that upgrades Cloudflare Workers to use the new manager API.

Todo List

• Read repository guidelines (CLAUDE.md)
• Analyze the core manager API changes in packages/rivetkit/src/registry/
• Review Cloudflare Workers implementation changes
• Check error handling and logging patterns
• Evaluate test coverage and quality
• Assess performance and security implications
• Provide comprehensive feedback

Review Summary

This PR successfully upgrades the Cloudflare Workers adapter to use the new manager API pattern. The changes are well-structured and maintain backward compatibility while modernizing the API design.

🎯 Code Quality & Best Practices

✅ Strengths:

• Clean separation of concerns between manager and actor drivers
• Proper use of TypeScript with strict typing
• Consistent error handling using the established ActorError hierarchy
• Good adherence to the project's coding standards (camelCase, structured logging, etc.)
• Proper configuration validation using Zod schemas

⚠️ Areas for improvement:

1. Configuration API Inconsistency (packages/cloudflare-workers/src/handler.ts:39-45):

   export function createHandler<R extends Registry<any>>(
   	registry: R,
   	inputConfig?: InputConfig,
   ): Handler {
   	const { createHandler } = createServer(registry, inputConfig);
   	return createHandler();
   }

   The function naming is confusing - createHandler calls createServer which returns a createHandler function. Consider renaming for clarity.

2. Commented Code in Example (examples/cloudflare-workers/scripts/client.ts:37-63):
   Large blocks of commented code should be removed rather than left in the codebase.

🐛 Potential Issues

Low Impact:

1. Missing Input Validation (packages/cloudflare-workers/src/handler.ts:80-87):

   if (url.pathname.startsWith(config.managerPath)) {
       const strippedPath = url.pathname.substring(
           config.managerPath.length,
       );
       url.pathname = strippedPath;

   No validation that config.managerPath is a valid path format. Consider adding validation in the config schema.

2. Error Context Loss (packages/rivetkit/src/registry/mod.ts:61-70):
   Driver-specific configuration overrides could benefit from debug logging to aid troubleshooting.

🚀 Performance Considerations

✅ Good practices:

• Lazy WebSocket upgrader initialization (packages/rivetkit/src/registry/mod.ts:73-76)
• Efficient path stripping for manager routes
• Proper async/await usage throughout

💡 Potential optimizations:

• URL parsing in the request handler could be cached for repeated requests to the same endpoint

🔒 Security Assessment

✅ Security practices observed:

• No sensitive data exposure in error messages
• Proper error boundary handling with public/private error classification
• Input validation using Zod schemas

✅ No security concerns identified - the changes maintain the existing security model appropriately.

🧪 Test Coverage & Quality

⚠️ Test observations:

1. Function Name Mismatch (packages/cloudflare-workers/tests/driver-tests.test.ts:202):

   const { handler, ActorHandler } = createServerHandler(registry);

   Test imports createServerHandler but the actual export is createHandler. This suggests the test may not be running or may be using an outdated import.

2. Hardcoded Values: The test setup uses hardcoded versions (wrangler: "^4.22.0", hono: "4.8.3") which could become outdated.

3. Missing Test for New API: No specific tests for the new createServer vs createHandler pattern.

📊 Architecture Assessment

✅ Well-designed changes:

• Clear separation between server setup and handler creation
• Consistent driver interface implementation
• Maintains compatibility with existing Cloudflare Workers patterns

💡 Suggestions:

1. Consider adding JSDoc comments for the new public APIs
2. The HACK comment in packages/rivetkit/src/registry/mod.ts:117 suggests this pattern needs refinement

✨ Recommendations

1. Fix the test import to use the correct function name
2. Remove commented code from the client example
3. Add validation for managerPath configuration
4. Consider renaming createHandler to createHandlerFunction or similar for clarity
5. Add debug logging for driver-specific configuration overrides

Overall Assessment

This is a solid refactoring that successfully modernizes the Cloudflare Workers adapter. The code quality is high, follows project conventions, and maintains backward compatibility. The main issues are minor and mostly relate to naming clarity and test accuracy.

✅ Recommend merging after addressing the test import issue and cleaning up the commented code.

---

[NathanFlurry]

• fix(core): fix endpoint not being respected in createClient #1255
• chore(core): simplify appending paths #1254
• chore(cloudflare-workers): upgrade to new manager api #1253 👈 (View in Graphite)
• 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.

[graphite-app]

Merge activity

• Sep 17, 12:24 AM UTC: NathanFlurry added this pull request to the Graphite merge queue.
• Sep 17, 12:24 AM UTC: CI is running for this pull request on a draft pull request (#1256) due to your merge queue CI optimization settings.
• Sep 17, 12:25 AM UTC: Merged by the Graphite merge queue via draft PR: #1256.