fix(serverless): read x-rivet-token from start endpoint

[MasterPtato]

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 1, 2025 4:26am

[claude]

Claude finished @MasterPtato's task —— View job

---

Code Review Complete ✅

Tasks:

• Read project guidelines from CLAUDE.md
• Analyze changed files for code quality
• Check for potential bugs and security issues
• Review performance considerations
• Assess test coverage needs
• Provide comprehensive feedback

---

📋 Review Summary

This PR fixes serverless functionality to properly read the x-rivet-token header from the start endpoint. The changes are minimal and focused, which is good for a bug fix.

✅ Positive Aspects

1. Focused Fix: The changes are minimal and directly address the issue without unnecessary modifications
2. Type Safety: Proper TypeScript parameter typing for the token parameter
3. Header Constants: Good use of existing header constant x-rivet-token from actor-router-consts.ts:21
4. Conditional Logic: Smart conditional token override only when a token is provided

🔍 Detailed Analysis

File: packages/rivetkit/src/manager/router.ts

• Line 108: Function signature updated to accept token parameter ✅
• Line 121: Correctly reads x-rivet-token header and passes to builder ✅
• Lines 172-174: Incidental formatting change (good) ✅

File: packages/rivetkit/src/registry/mod.ts

• Line 218: Function signature matches router change ✅
• Lines 219-220: Conditional token override logic is sound ✅

🔐 Security Considerations

• Token Handling: The token is properly passed through the request header x-rivet-token which is already defined in the allowed public headers (actor-router-consts.ts:58) ✅
• No Exposure: Token is not logged or exposed in the codebase ✅
• Conditional Override: Only overrides config when token is explicitly provided ✅

⚡ Performance Considerations

• Minimal Overhead: The header read operation has negligible performance impact ✅
• No Memory Leaks: No additional object creation or retention concerns ✅

🧪 Test Coverage Assessment

Observation: No specific tests found for serverless token handling functionality. However, this is a relatively simple fix that:

• Reads a header value (standard Hono operation)
• Passes it to an existing function
• Conditionally assigns a config value

Recommendation: Consider adding integration tests for serverless scenarios with token authentication, but the current change is low-risk.

🏗️ Code Quality

• Follows Project Guidelines: Adheres to CLAUDE.md conventions ✅
• Type Safety: Proper TypeScript usage ✅
• Error Handling: Leverages existing error handling patterns ✅
• Code Style: Consistent with existing codebase ✅

📝 Minor Observations

1. The incidental formatting change in router.ts (lines 172-174) appears to be an IDE auto-format - this is fine and improves consistency
2. The logic correctly handles undefined tokens by only overriding when explicitly provided

🎯 Overall Assessment

APPROVED ✅ This is a well-implemented bug fix that:

• Solves the stated problem
• Maintains type safety
• Follows security best practices
• Has minimal risk of introducing new bugs
• Adheres to project conventions

The changes are production-ready and should be safe to merge.

---

[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@1315

@rivetkit/cloudflare-workers

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

@rivetkit/core

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

@rivetkit/db

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

@rivetkit/framework-base

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

@rivetkit/next-js

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

@rivetkit/react

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

rivetkit

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

@rivetkit/sql-loader

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

commit: c8c5678

[abcxff]

• fix(serverless): read x-rivet-token from start endpoint #1315 : 3 dependent PRs (#1316 , #1317 , #1320 ) 👈 (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.

[claude]

Claude finished @MasterPtato's task —— View job

---

📋 Code Review Complete ✅

Tasks:

• Read project guidelines from CLAUDE.md
• Analyze changed files for code quality
• Check for potential bugs and security issues
• Review performance considerations
• Assess test coverage needs
• Provide comprehensive feedback

---

📋 Review Summary

This PR fixes serverless functionality to properly read the x-rivet-token header from the start endpoint. The changes are minimal and focused, which is good for a bug fix.

✅ Positive Aspects

1. Focused Fix: The changes are minimal and directly address the issue without unnecessary modifications
2. Type Safety: Proper TypeScript parameter typing for the token parameter
3. Header Constants: Good use of existing header constant HEADER_RIVET_TOKEN from actor-router-consts.ts:21
4. Conditional Logic: Smart conditional token override only when a token is provided

🔍 Detailed Analysis

File: packages/rivetkit/src/manager/router.ts

• Line 108: Function signature updated to accept token parameter ✅
• Line 121: Correctly reads x-rivet-token header and passes to builder ✅
• Lines 172-174: Incidental formatting change (good) ✅

File: packages/rivetkit/src/registry/mod.ts

• Line 218: Function signature matches router change ✅
• Lines 219-220: Conditional token override logic is sound ✅

🔐 Security Considerations

• Token Handling: The token is properly passed through the request header x-rivet-token which is already defined in the allowed public headers (actor-router-consts.ts:58) ✅
• No Exposure: Token is not logged or exposed in the codebase ✅
• Conditional Override: Only overrides config when token is explicitly provided ✅

⚡ Performance Considerations

• Minimal Overhead: The header read operation has negligible performance impact ✅
• No Memory Leaks: No additional object creation or retention concerns ✅

🧪 Test Coverage Assessment

Observation: No specific tests found for serverless token handling functionality. However, this is a relatively simple fix that:

• Reads a header value (standard Hono operation)
• Passes it to an existing function
• Conditionally assigns a config value

Recommendation: Consider adding integration tests for serverless scenarios with token authentication, but the current change is low-risk.

🏗️ Code Quality

• Follows Project Guidelines: Adheres to CLAUDE.md conventions ✅
• Type Safety: Proper TypeScript usage ✅
• Error Handling: Leverages existing error handling patterns ✅
• Code Style: Consistent with existing codebase ✅

📝 Minor Observations

1. The incidental formatting change in router.ts (lines 172-174) appears to be an IDE auto-format - this is fine and improves consistency
2. The logic correctly handles undefined tokens by only overriding when explicitly provided

🎯 Overall Assessment

APPROVED ✅ This is a well-implemented bug fix that:

• Solves the stated problem
• Maintains type safety
• Follows security best practices
• Has minimal risk of introducing new bugs
• Adheres to project conventions

The changes are production-ready and should be safe to merge.

---

[claude]

Claude finished @MasterPtato's task —— View job

---

Code Review Complete ✅

Tasks:

• Read project guidelines from CLAUDE.md
• Analyze changed files for code quality
• Check for potential bugs and security issues
• Review performance considerations
• Assess test coverage needs
• Provide comprehensive feedback

---

📋 Review Summary

This PR fixes serverless functionality to properly read the x-rivet-token header from the start endpoint. The changes are minimal and focused, which is excellent for a bug fix.

✅ Positive Aspects

1. Focused Fix: The changes are minimal and directly address the issue without unnecessary modifications
2. Type Safety: Proper TypeScript parameter typing for the token parameter
3. Header Constants: Good use of existing header constant HEADER_RIVET_TOKEN from actor-router-consts.ts:21
4. Conditional Logic: Smart conditional token override only when a token is provided
5. Security Compliance: Token is properly handled via secure headers as documented in the constants file

🔍 Detailed Analysis

File: packages/rivetkit/src/manager/router.ts

• Line 108: Function signature updated to accept optional token parameter ✅
• Line 121: Correctly reads x-rivet-token header using c.req.header() and passes to builder ✅
• Clean implementation that follows existing patterns in the codebase

File: packages/rivetkit/src/registry/mod.ts

• Line 218: Function signature matches router change with proper typing ✅
• Lines 219-220: Sound conditional token override logic - only overrides when token is explicitly provided ✅
• Maintains existing config structure while allowing token override

🔐 Security Considerations

• Token Handling: The token is properly passed through the request header x-rivet-token which is already defined in the allowed public headers (actor-router-consts.ts:58) ✅
• No Exposure: Token is not logged or exposed in the codebase ✅
• Conditional Override: Only overrides config when token is explicitly provided, preventing unintentional token clearing ✅
• Secure Transport: Uses headers rather than URL parameters as recommended in the constants file comments ✅

⚡ Performance Considerations

• Minimal Overhead: The header read operation has negligible performance impact ✅
• No Memory Leaks: No additional object creation or retention concerns ✅
• Lazy Evaluation: Token is only processed when provided ✅

🧪 Test Coverage Assessment

Observation: This is a relatively simple fix with low complexity:

• Reads a header value (standard Hono operation)
• Passes it to an existing function
• Conditionally assigns a config value

Recommendation: While the current change is low-risk, consider adding integration tests for serverless scenarios with token authentication to ensure the fix works end-to-end.

🏗️ Code Quality

• Follows Project Guidelines: Adheres to CLAUDE.md conventions ✅
• Type Safety: Proper TypeScript usage with optional parameter typing ✅
• Error Handling: Leverages existing error handling patterns ✅
• Code Style: Consistent with existing codebase formatting and patterns ✅
• Import Usage: Correctly uses existing constants rather than hardcoding strings ✅

📝 Minor Observations

1. The function parameter correctly uses string | undefined typing, which is appropriate for optional header values
2. The logic properly handles undefined tokens by only overriding when explicitly provided
3. No breaking changes to existing API surface

🎯 Overall Assessment

APPROVED ✅ This is a well-implemented bug fix that:

• Solves the stated problem elegantly
• Maintains type safety throughout
• Follows security best practices
• Has minimal risk of introducing new bugs
• Adheres to project conventions
• Uses existing infrastructure appropriately

The changes are production-ready and should be safe to merge. The implementation is clean, focused, and follows established patterns in the codebase.

---

[graphite-app]

Merge activity

• Oct 1, 4:29 AM UTC: NathanFlurry added this pull request to the Graphite merge queue.
• Oct 1, 4:30 AM UTC: CI is running for this pull request on a draft pull request (#1321) due to your merge queue CI optimization settings.
• Oct 1, 4:31 AM UTC: Merged by the Graphite merge queue via draft PR: #1321.