fix(next-js): fix auto-configure in prod

[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 10:53pm

[claude]

Claude finished @NathanFlurry's task —— View job

---

Code Review for Next.js Auto-Configure Fix

Reviewing PR #1385: fix(next-js): fix auto-configure in prod

Todo List:

• Read and analyze changed files
• Review code quality and best practices
• Check for potential bugs or issues
• Evaluate performance considerations
• Assess security concerns
• Review test coverage
• Provide comprehensive feedback

---

Summary of Changes

This PR adds logging functionality and improves the environment-based configuration logic in the Next.js integration. The changes include:

1. New file: packages/next-js/src/log.ts - Adds logging capability
2. Modified: packages/next-js/src/mod.ts - Adds debug logging for development vs production behavior

Code Quality & Best Practices ✅

Positive aspects:

• Follows repository conventions: The logging implementation correctly uses getLogger from rivetkit/log and follows the established pattern from CLAUDE.md
• Consistent naming: Uses "driver-next-js" as the logger name, following the driver naming convention
• Clean separation: Logging functionality is properly separated into its own module
• Follows established patterns: The logger function follows the repository guideline to always call logger() rather than storing it

Code style compliance:

• Uses lowercase log messages as per CLAUDE.md guidelines ✅
• Imports are properly organized ✅
• Follows camelCase naming conventions ✅

Potential Bugs & Issues ⚠️

Minor concerns:

1. URL construction: The publicUrl construction logic remains the same but could benefit from validation:

   const publicUrl =
       process.env.NEXT_PUBLIC_SITE_URL ??
       process.env.NEXT_PUBLIC_VERCEL_URL ??
       `http://127.0.0.1:${process.env.PORT ?? 3000}`;

   • Missing protocol handling for NEXT_PUBLIC_VERCEL_URL (Vercel URLs are typically without protocol)
   • No validation that the constructed URL is valid

Recommendations:

// More robust URL handling
let publicUrl = process.env.NEXT_PUBLIC_SITE_URL;
if (!publicUrl) {
    const vercelUrl = process.env.NEXT_PUBLIC_VERCEL_URL;
    publicUrl = vercelUrl ? `https://${vercelUrl}` : `http://127.0.0.1:${process.env.PORT ?? 3000}`;
}

Performance Considerations ✅

Good practices:

• Logger calls are only made once per function invocation
• Environment variable reads are efficient (cached by Node.js)
• The debug logging only occurs during initialization, not on every request
• No performance impact in production (debug logs are typically filtered out)

Security Concerns ✅

Security assessment:

• Environment variable handling: Properly uses environment variables without exposing sensitive data
• No secrets exposure: The logged information (environment detection) is safe to log
• URL construction: Uses safe defaults and environment-provided URLs
• No injection risks: The logging content is safe and controlled

Test Coverage ❌

Missing tests:

• No unit tests found for the Next.js package
• The logging functionality is not tested
• Environment detection logic is not tested
• URL construction logic is not tested

Recommendation: Consider adding tests for:

describe('toNextHandler', () => {
  it('should enable auto-configure in development', () => {
    // Test NODE_ENV !== 'production' path
  });
  
  it('should disable auto-configure in production', () => {
    // Test NODE_ENV === 'production' path
  });
  
  it('should construct correct URLs from environment variables', () => {
    // Test URL construction logic
  });
});

Architecture & Design ✅

Well-designed aspects:

• Clear separation of concerns: Logging is separated into its own module
• Environment-aware configuration: Proper handling of dev vs prod environments
• Backwards compatibility: No breaking changes to the public API
• Consistent with framework patterns: Follows Next.js API route handler conventions

Documentation 📝

Observations:

• The PR lacks a description, making it harder to understand the specific issue being fixed
• The debug messages are informative and explain the behavior clearly
• Code comments remain relevant and helpful

Overall Assessment ✅

This is a solid, low-risk improvement that adds valuable debugging capabilities without changing core functionality. The code follows repository conventions well and maintains backwards compatibility.

Key strengths:

• Follows established coding patterns and guidelines
• Adds helpful debugging information
• Clean, readable implementation
• No breaking changes

Areas for improvement:

• Add unit tests for the functionality
• Consider more robust URL validation
• Provide a PR description explaining the specific production issue being fixed

Risk level: Low - This is a safe addition that improves observability

---

[NathanFlurry]

• chore(core): add actor names to metadata endpoint #1387
• fix(next-js): fix auto-configure in prod #1385 👈 (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.

[pkg-pr-new]

More templates

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

@rivetkit/actor

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

@rivetkit/cloudflare-workers

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

@rivetkit/core

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

@rivetkit/db

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

@rivetkit/framework-base

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

@rivetkit/next-js

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

@rivetkit/react

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

rivetkit

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

@rivetkit/sql-loader

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

commit: 307a5b6

[claude]

Claude finished @NathanFlurry's task —— View job

---

PR Code Review - Next.js Auto-Configure Fix

Reviewing PR #1385: fix(next-js): fix auto-configure in prod

Todo List:

• Read and analyze changed files
• Review code quality and best practices
• Check for potential bugs or issues
• Evaluate performance considerations
• Assess security concerns
• Review test coverage
• Provide comprehensive feedback

---

Summary of Changes

This PR adds logging functionality to improve visibility into Next.js integration behavior, specifically around development vs production environment detection and auto-configuration logic.

Files Changed Analysis

New file: packages/next-js/src/log.ts

• Adds a logger function that returns a logger with "driver-next-js" identifier
• Follows repository logging conventions from CLAUDE.md

Modified: packages/next-js/src/mod.ts

• Adds debug logging for development vs production environment detection
• Uses the new logger to provide visibility into auto-configuration behavior

Modified: packages/rivetkit/src/drivers/default.ts

• Adds structured debug logging when choosing the Rivet engine driver
• Logs endpoint information for debugging

Code Quality & Best Practices ✅

Excellent adherence to repository conventions:

• Logging pattern: Correctly uses getLogger from rivetkit/log and follows CLAUDE.md guideline to call logger() rather than storing it (packages/next-js/src/log.ts:3-4)
• Naming consistency: Uses "driver-next-js" logger name following driver naming patterns
• Message formatting: Uses lowercase log messages as required (packages/next-js/src/mod.ts:16-17, 30-31)
• Structured logging: Uses proper structured logging format in packages/rivetkit/src/drivers/default.ts:26-29
• Clean separation: Logging functionality properly separated into its own module

Potential Bugs & Issues ⚠️

Minor URL construction concern in packages/next-js/src/mod.ts:20-23:

const publicUrl =
    process.env.NEXT_PUBLIC_SITE_URL ??
    process.env.NEXT_PUBLIC_VERCEL_URL ??
    `http://127.0.0.1:${process.env.PORT ?? 3000}`;

• Issue: NEXT_PUBLIC_VERCEL_URL typically doesn't include protocol, but code assumes it does
• Potential fix: Add protocol handling for Vercel URLs
• Impact: Could cause invalid URLs in Vercel deployments during development

Recommendation:

let publicUrl = process.env.NEXT_PUBLIC_SITE_URL;
if (!publicUrl) {
    const vercelUrl = process.env.NEXT_PUBLIC_VERCEL_URL;
    publicUrl = vercelUrl ? `https://${vercelUrl}` : `http://127.0.0.1:${process.env.PORT ?? 3000}`;
}

Performance Considerations ✅

Positive performance aspects:

• Logger calls only occur once during handler initialization, not on every request
• Environment variable reads are cached by Node.js runtime
• Debug logs are typically filtered out in production builds
• No impact on request handling performance
• Minimal memory footprint for logging functionality

Security Concerns ✅

Security assessment:

• Environment variable handling: Safely uses environment variables without exposing sensitive data
• Logging content: Debug messages are safe and don't leak secrets or sensitive information
• URL construction: Uses environment-provided URLs and safe defaults
• No injection risks: All logged content is controlled and safe

Test Coverage ❌

Missing test coverage:

• No unit tests found for the Next.js package (packages/next-js/)
• New logging functionality is untested
• Environment detection logic lacks test coverage
• URL construction behavior is not verified through tests

Recommendations:

describe('toNextHandler', () => {
  describe('environment detection', () => {
    it('should enable auto-configure in development', () => {
      process.env.NODE_ENV = 'development';
      // Test that runEngine is true and autoConfigureServerless is set
    });
    
    it('should disable auto-configure in production', () => {
      process.env.NODE_ENV = 'production';
      // Test that runEngine and autoConfigureServerless are not set
    });
  });
  
  describe('URL construction', () => {
    it('should use NEXT_PUBLIC_SITE_URL when available', () => {
      process.env.NEXT_PUBLIC_SITE_URL = 'https://example.com';
      // Test URL construction
    });
    
    it('should handle NEXT_PUBLIC_VERCEL_URL correctly', () => {
      process.env.NEXT_PUBLIC_VERCEL_URL = 'my-app-preview.vercel.app';
      // Test protocol addition
    });
  });
});

Overall Assessment ✅

This is a solid, low-risk improvement that adds valuable observability without changing core functionality.

Strengths:

• Excellent adherence to repository coding standards and guidelines
• Clean, readable implementation with proper separation of concerns
• Valuable debugging information for troubleshooting environment issues
• No breaking changes or performance impact
• Follows established logging patterns consistently

Areas for improvement:

• Consider fixing the URL construction logic for better Vercel compatibility
• Add unit tests to verify behavior and prevent regressions
• PR description would help explain the specific production issue being addressed

Risk Level: Low - Safe addition that improves debugging capabilities

Recommendation: ✅ Approve - This is a well-implemented enhancement that follows best practices and adds value

---

[graphite-app]

Merge activity

• Oct 14, 10:39 PM UTC: NathanFlurry added this pull request to the Graphite merge queue.
• Oct 14, 10:39 PM UTC: CI is running for this pull request on a draft pull request (#1388) due to your merge queue CI optimization settings.
• Oct 14, 10:40 PM UTC: Merged by the Graphite merge queue via draft PR: #1388.