chore(rivetkit): validate incoming serverless request endpoint/namespace

[NathanFlurry]

No description provided.

[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

• doc: update railway integration guide for serverless #3897
• doc: configuring rivet endpoints #3895
• chore(rivetkit): validate incoming serverless request endpoint/namespace #3894 👈 (View in Graphite)
• chore(rivetkit): update welcome message #3893
• feat(rivetkit): allow defining public namespace & token for client redirects via metadata endpoint #3891
• chore(engine): provide detailed error for invalid serverless sse event #3881 : 1 other dependent PR (#3890 )
• main

---

How to use the Graphite Merge Queue

Add the label merge-queue to this PR to add it to the merge queue.

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.

[claude]

Pull Request Review

Summary

This PR adds validation to the serverless router to ensure that incoming requests match the expected endpoint and namespace configuration. This helps catch misconfigurations and potentially malicious requests.

Code Quality ✅

Strengths:

• Clean implementation with clear intent
• Good error handling with appropriate HTTP 400 status codes
• Helpful error messages that include both expected and received values
• Well-structured comment explaining the validation logic (lines 55-60)

Style & Conventions:

• Follows existing error handling patterns in the codebase
• Consistent with other ActorError subclasses
• Import organization is clean and alphabetized

Potential Issues & Suggestions

1. Logic Clarification ⚠️

The validation only checks the namespace when config.endpoint is set (line 61). The comment explains this is intentional, but the logic could be more explicit:

// Current:
if (config.endpoint) {
    if (endpoint !== config.endpoint) {
        throw new EndpointMismatch(config.endpoint, endpoint);
    }
    
    if (namespace !== config.namespace) {
        throw new NamespaceMismatch(config.namespace, namespace);
    }
}

Consider whether namespace validation should be independent of endpoint configuration. If a user configures a namespace without an endpoint, should it still be validated?

2. Missing Test Coverage 🔴

This is a security-related validation feature, but there are no tests covering:

• Valid requests that should pass validation
• Mismatched endpoint scenarios
• Mismatched namespace scenarios
• Behavior when config.endpoint is undefined
• Edge cases (empty strings, special characters, etc.)

Recommendation: Add tests similar to the pattern in src/actor/utils.test.ts to cover these scenarios.

3. Potential Edge Case: Undefined vs Empty String ⚠️

The validation uses strict equality (!==), which is correct, but consider what happens if:

• config.endpoint is an empty string (would trigger validation)
• config.namespace is undefined or empty

Based on the RegistryConfigSchema (line 99-102 in config/index.ts), namespace defaults to "default" if not provided, so this should be safe. However, explicit handling might be clearer.

4. Error Group Consistency 💭

The new errors use "config" as the error group, which is appropriate. However, you might also consider:

• "validation" - if this is primarily about request validation
• "auth" - if this is security-focused (though the current choice is fine)

The current choice of "config" is reasonable since these are configuration mismatches.

5. Documentation 📝

Consider adding JSDoc comments to the new error classes to explain when they're thrown:

/**
 * Thrown when the incoming serverless request's endpoint doesn't match 
 * the configured endpoint. This helps prevent misconfigured deployments
 * and potential security issues.
 */
export class EndpointMismatch extends ActorError {
    // ...
}

Security Considerations ✅

Positive:

• Good defense-in-depth approach to catch misconfigurations
• Error messages are safe to expose (marked as public: true)
• Appropriate status code (400) for client errors
• Metadata includes useful debugging information without exposing sensitive data

Note: Since these errors are marked as public and include the expected values in the error message, ensure that config.endpoint and config.namespace don't contain sensitive information (like tokens). Based on the config schema, tokens are separate from endpoints, so this should be safe.

Performance Considerations ✅

No performance concerns. The validation is:

• Two simple string comparisons
• Only executed on serverless start requests (not on every request)
• Fail-fast with early returns

Overall Assessment

Score: 7.5/10

This is a solid security improvement with clean implementation. The main areas for improvement are:

1. Must Have: Add comprehensive test coverage
2. Should Have: Consider whether namespace validation should be independent of endpoint
3. Nice to Have: Add JSDoc comments to the error classes

The code is production-ready from a functionality standpoint, but the lack of tests is a significant gap for a security-related feature.

Recommendations

Before merging:

• Add test coverage for the validation logic

Future improvements:

• Consider adding JSDoc comments
• Review whether namespace validation logic matches all intended use cases

---

Great work on improving security and configuration validation! 🎉

[pkg-pr-new]

More templates

• actor-actions
• example-ai-agent
• example-ai-and-user-generated-actors-freestyle
• chat-room
• example-cloudflare-workers
• example-cloudflare-workers-hono
• example-cloudflare-workers-inline-client
• cross-actor-actions
• example-cursors
• example-cursors-raw-websocket
• custom-serverless
• example-sqlite
• example-elysia
• example-experimental-durable-streams-ai-agent
• hello-world
• example-hono
• hono-react
• example-kitchen-sink
• multi-region
• native-websockets
• next-js
• example-raw-fetch-handler
• example-raw-websocket-handler
• example-raw-websocket-handler-proxy
• example-react
• scheduling
• state
• example-stream
• example-trpc

@rivetkit/cloudflare-workers

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

@rivetkit/db

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

@rivetkit/framework-base

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

@rivetkit/next-js

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

@rivetkit/react

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

rivetkit

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

@rivetkit/sql-loader

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

@rivetkit/virtual-websocket

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/virtual-websocket@3894

@rivetkit/engine-runner

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/engine-runner@3894

@rivetkit/engine-runner-protocol

pnpm add https://pkg.pr.new/rivet-dev/rivet/@rivetkit/engine-runner-protocol@3894

commit: 272eaeb

[graphite-app]

Merge activity

• Jan 14, 8:52 PM UTC: NathanFlurry added this pull request to the Graphite merge queue.
• Jan 14, 8:53 PM UTC: CI is running for this pull request on a draft pull request (#3898) due to your merge queue CI optimization settings.
• Jan 14, 8:53 PM UTC: Merged by the Graphite merge queue via draft PR: #3898.