fix(core): do not redirect client endpoint if default server disabled

[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 13, 2025 6:40pm

[claude]

Claude finished @NathanFlurry's task —— View job

---

Code Review Complete ✅

Reviewing pull request: fix(core): do not redirect client endpoint if default server disabled

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze the modified file and understand the change
• Review git diff to see exact modifications
• Assess code quality and best practices
• Check for potential bugs or issues
• Evaluate performance considerations
• Review security concerns
• Assess test coverage needs
• Provide comprehensive feedback

---

Review Feedback

✅ Overall Assessment: LGTM - Good Fix

This is a well-targeted bug fix that properly handles the conditional logic for client endpoint redirection when the default server is disabled.

Code Quality & Best Practices

• ✅ Code follows repository style guidelines: Uses camelCase, proper formatting, and follows existing patterns
• ✅ Good use of ternary operator: The conditional logic is clear and readable
• ✅ Helpful comment: The inline comment explains the purpose of the change
• ✅ Proper fallback logic: Uses nullish coalescing (??) to check overrideServerAddress first

Logic Analysis

The change implements this priority order for clientEndpoint:

1. runConfig.overrideServerAddress (if set) - highest priority
2. undefined (if disableDefaultServer is true) - prevents redirect
3. getEndpoint(runConfig) (default behavior) - fallback

This logic is correct and matches the expected behavior based on the usage patterns in examples.

Potential Issues

• ✅ No bugs identified: The conditional logic correctly prevents client endpoint redirection when the default server is disabled
• ✅ Backward compatibility: Existing behavior is preserved when disableDefaultServer is false
• ✅ Type safety: All properties exist on RunnerConfig interface

Performance Considerations

• ✅ Minimal impact: Simple conditional check with no performance implications
• ✅ Efficient evaluation: Short-circuits appropriately with nullish coalescing and ternary

Security Concerns

• ✅ No security issues: The change doesn't introduce any security vulnerabilities
• ✅ Proper endpoint handling: Maintains existing security patterns for endpoint configuration

Test Coverage Assessment

⚠️ Recommendation: Consider adding tests for this specific scenario:

// Test cases to consider
describe('handleMetadataRequest clientEndpoint', () => {
  it('should return overrideServerAddress when set', () => {
    // Test overrideServerAddress takes precedence
  });
  
  it('should return undefined when disableDefaultServer is true and no override', () => {
    // Test the new behavior
  });
  
  it('should return getEndpoint result when disableDefaultServer is false', () => {
    // Test default behavior is preserved
  });
});

Context Validation

Looking at the examples (hono-bun, freestyle, deno), this change correctly addresses a real use case where:

• disableDefaultServer: true is used when integrating with external frameworks
• overrideServerAddress specifies the actual endpoint clients should use
• Without this fix, the metadata endpoint would incorrectly return the internal endpoint

Minor Suggestions

1. Documentation: The JSDoc comment on line 97-104 is excellent and explains the clientEndpoint field purpose well
2. Consistency: The change follows the existing code style and patterns in the file

---

Verdict: ✅ Approve - This is a clean, targeted fix that properly handles the conditional logic without introducing any issues.

[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(example-hono-bun): add frontend to example #1381
• fix(core): do not redirect client endpoint if default server disabled #1382 👈 (View in Graphite)
• fix(core): fix endpoint undefined log #1380
• 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

• Oct 13, 6:24 PM UTC: NathanFlurry added this pull request to the Graphite merge queue.
• Oct 13, 6:25 PM UTC: CI is running for this pull request on a draft pull request (#1383) due to your merge queue CI optimization settings.
• Oct 13, 6:26 PM UTC: Merged by the Graphite merge queue via draft PR: #1383.