Skip to content

Conversation

NathanFlurry
Copy link
Member

No description provided.

Copy link

vercel bot commented Oct 5, 2025

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

Project Deployment Preview Comments Updated (UTC)
rivetkit-serverless Ready Ready Preview Comment Oct 5, 2025 10:02pm

Copy link

claude bot commented Oct 5, 2025

Claude finished @NathanFlurry's task —— View job


PR Review: feat(core): support running engine

Todo List:

  • Read repository guidelines (CLAUDE.md)
  • Analyze changed files and understand the implementation
  • Review code quality and best practices
  • Check for potential bugs and issues
  • Evaluate performance considerations
  • Assess security concerns
  • Review test coverage
  • Provide comprehensive feedback

Analysis Summary

This PR adds support for running a Rivet engine process automatically within the RivetKit runtime. The implementation includes:

  1. New engine-process module (packages/rivetkit/src/engine-process/mod.ts) - Handles downloading, caching, and spawning the Rivet engine binary
  2. Registry modifications - Adds runEngine configuration option and synchronous process management
  3. File system utils changes - Updates to directory management utilities (with debug code)
  4. Test coverage - Basic tests for platform-specific binary resolution

🚨 Critical Issues

1. Debug Code Left in Production (packages/rivetkit/src/drivers/file-system/utils.ts)

Lines 59-84: Debug code and disabled functionality must be removed before merging:

// These debug statements should be removed:
console.log("check 1 ====");
console.trace("pathExists checking ======== lksjdflkdsjf", path);
return false; // This breaks pathExists functionality!

// In ensureDirectoryExists:
throw "ERROR"; // This will always throw!

Impact: This completely breaks file system operations and will cause runtime failures.

2. Synchronous Async Operations (packages/rivetkit/src/registry/mod.ts:76-78)

The waitForPromiseSync function blocks the event loop using Atomics.wait:

engineProcessState = waitForPromiseSync(
    ensureEngineProcess({ version: engineVersion }),
);

Issues:

  • Blocks the Node.js event loop during engine startup
  • May cause timeouts in serverless environments
  • Not compatible with all JavaScript runtimes
  • Could impact application responsiveness

Recommendation: Consider making the entire start() method async or implement lazy initialization.


🐛 Bugs and Issues

3. Debug Console Logs in Engine Process (packages/rivetkit/src/engine-process/mod.ts)

Lines 32, 36-38, 45, 115, 117, 119: Debug console.log statements should be removed:

console.log('==== point 1');
console.log('==== point 2');
// ... more debug logs

4. Hardcoded Default Values

packages/rivetkit/src/registry/run-config.ts:50: Hardcoded engine version "25.7.3" should be:

  • Documented why this specific version is chosen
  • Consider making it configurable via a constants file
  • Ensure this version is tested and stable

5. Process Management Edge Cases

packages/rivetkit/src/engine-process/mod.ts:234-243: The isProcessRunning function may have edge cases:

  • Returns true for EPERM (correct)
  • But may not handle all process states correctly across platforms

🔒 Security Concerns

6. Binary Download Security

packages/rivetkit/src/engine-process/mod.ts:139-163:

  • Good: Uses HTTPS URL (https://releases.rivet.gg/engine)
  • ⚠️ Missing: No integrity verification (SHA checksum validation)
  • ⚠️ Risk: Downloaded binaries are not verified before execution

Recommendation: Add SHA256 checksum verification for downloaded binaries.

7. Environment Variable Exposure

packages/rivetkit/src/engine-process/mod.ts:67-71:

  • Admin token defaults to "dev" which could be a security risk in production
  • Consider validating that production deployments use proper tokens

⚡ Performance Considerations

8. File System Operations

  • Multiple file existence checks could be optimized
  • Consider caching version information to reduce I/O

9. Process Spawning

  • ✅ Good use of stdio: "inherit" for logging
  • ✅ Proper cleanup on process exit
  • Process reuse logic is well implemented

🧪 Test Coverage

Current Tests

packages/rivetkit/tests/engine-process.test.ts: Only tests resolveTargetTripletFor function.

Missing Test Coverage

  • Engine binary download logic
  • Process spawning and management
  • Error handling scenarios
  • Platform-specific behavior
  • File system operations
  • Configuration validation

Recommendations:

  1. Add integration tests for engine process lifecycle
  2. Mock file system operations for unit tests
  3. Test error scenarios (network failures, permission issues)
  4. Test process cleanup on various exit conditions

✅ Positive Aspects

  1. Good error handling - Comprehensive error messages and logging
  2. Cross-platform support - Proper platform detection and binary selection
  3. Process lifecycle management - Proper cleanup and PID file management
  4. Configuration flexibility - Good use of environment variables and defaults
  5. Logging practices - Follows repo guidelines with structured logging
  6. Code organization - Clean separation of concerns

📋 Action Items

Before merging:

  1. CRITICAL: Remove all debug code from file-system/utils.ts
  2. CRITICAL: Fix the broken pathExists and ensureDirectoryExists functions
  3. Remove debug console.log statements from engine-process module
  4. Consider architectural alternatives to waitForPromiseSync
  5. Add binary integrity verification
  6. Expand test coverage significantly

Post-merge considerations:

  1. Monitor performance impact of synchronous operations
  2. Add integration tests for the full engine lifecycle
  3. Consider adding configuration for engine release channels

Overall Assessment

This is a valuable feature that enables automatic engine management, but it has critical issues that must be addressed before merging. The file system utilities are completely broken by debug code, which will cause runtime failures.

Recommendation: ❌ Request changes - Address critical issues before approval.


Copy link
Member Author

NathanFlurry commented Oct 5, 2025

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


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.

Comment on lines 59 to 63
console.log("check 1 ====");
try {
await fs.access(path);
return true;
} catch {
console.log("check 2 ====");
console.trace("pathExists checking ======== lksjdflkdsjf", path);
return false;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pathExists function has been modified to always return false in the try block without actually checking if the path exists. This breaks the function's intended behavior.

The original implementation correctly used fs.access(path) to check for path existence, returning true when the path exists and catching exceptions when it doesn't.

Please restore the original implementation:

try {
  await fs.access(path);
  return true;
} catch {
  return false;
}

The debug logging can be kept if needed, but the core functionality should be preserved.

Suggested change
console.log("check 1 ====");
try {
await fs.access(path);
return true;
} catch {
console.log("check 2 ====");
console.trace("pathExists checking ======== lksjdflkdsjf", path);
return false;
console.log("check 1 ====");
try {
console.log("check 2 ====");
console.trace("pathExists checking ======== lksjdflkdsjf", path);
await fs.access(path);
return true;
} catch {
return false;

Spotted by Diamond

Fix in Graphite


Is this helpful? React 👍 or 👎 to let us know.

): Promise<void> {
console.log("ensuring path ====", directoryPath);
if (!(await pathExists(directoryPath))) {
throw "ERROR";
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The throw "ERROR"; statement prevents the directory creation logic from executing. This appears to be debugging code that was accidentally left in the PR. Removing this line will allow the function to properly create directories when they don't exist, which is the intended behavior of ensureDirectoryExists().

Spotted by Diamond

Fix in Graphite


Is this helpful? React 👍 or 👎 to let us know.

Copy link

pkg-pr-new bot commented Oct 5, 2025

More templates

@rivetkit/actor

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

@rivetkit/cloudflare-workers

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

@rivetkit/core

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

@rivetkit/db

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

@rivetkit/framework-base

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

@rivetkit/next-js

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

@rivetkit/react

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

rivetkit

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

@rivetkit/sql-loader

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

commit: 4fcc430

@NathanFlurry NathanFlurry force-pushed the 10-04-feat_core_support_running_engine branch from e42ae28 to d97a688 Compare October 5, 2025 07:06
Copy link

claude bot commented Oct 5, 2025

Claude finished @NathanFlurry's task —— View job


Reviewing PR: feat(core): support running engine

Todo List:

  • Read repository guidelines (CLAUDE.md)
  • Analyze changed files and understand the implementation
  • Review code quality and best practices
  • Check for potential bugs and issues
  • Evaluate performance considerations
  • Assess security concerns
  • Review test coverage
  • Provide comprehensive feedback

Analysis Summary

This PR adds support for running a Rivet engine process automatically within the RivetKit runtime. The implementation includes:

  1. New engine-process module (packages/rivetkit/src/engine-process/mod.ts) - Handles downloading, caching, and spawning the Rivet engine binary
  2. Registry modifications - Adds runEngine configuration option and async process management
  3. Configuration updates - Adds engine version and related settings to run config
  4. Test coverage - Basic tests for platform-specific binary resolution

🚨 Critical Issues

1. Asynchronous Promise Handling in Synchronous Context (packages/rivetkit/src/registry/mod.ts:87-93)

The engine process is started asynchronously but the start() method is synchronous, which could lead to race conditions:

// Start the engine
const engineProcessPromise = ensureEngineProcess({
    version: config.runEngineVersion,
});

// Chain ready promise
readyPromises.push(engineProcessPromise);

Issue: The actor driver starts before the engine process is guaranteed to be ready, potentially causing connection failures.

Recommendation: Consider making the entire start() method async or implement proper synchronization.


🐛 Bugs and Issues

2. Hardcoded Default Values (packages/rivetkit/src/registry/run-config.ts:50)

Line 50: Hardcoded engine version "25.7.3" should be:

  • Documented why this specific version is chosen
  • Consider making it configurable via a constants file
  • Ensure this version is tested and stable

3. Missing Error Context (packages/rivetkit/src/engine-process/mod.ts:176-181)

Lines 176-181: HTTP download error lacks request headers/details that could aid debugging:

throw new Error(
    `failed to download rivet engine binary from ${downloadUrl}: ${response.status} ${response.statusText}`,
);

Recommendation: Include response headers or additional context for debugging network issues.

4. Platform Support Limitations (packages/rivetkit/src/engine-process/mod.ts:226-250)

Lines 226-250: Limited platform support - missing ARM64 Linux and other common architectures:

case "linux":
    if (arch === "x64") {
        return { targetTriplet: "x86_64-unknown-linux-musl", extension: "" };
    }
    break;

Missing: ARM64 Linux support is becoming increasingly important (Apple Silicon, ARM-based cloud instances).


🔒 Security Concerns

5. Binary Download Security (packages/rivetkit/src/engine-process/mod.ts:176-188)

  • Good: Uses HTTPS URL (https://releases.rivet.gg/engine)
  • ⚠️ Missing: No integrity verification (SHA checksum validation)
  • ⚠️ Risk: Downloaded binaries are not verified before execution

Recommendation: Add SHA256 checksum verification for downloaded binaries.

6. Default Admin Token (packages/rivetkit/src/engine-process/mod.ts:91)

Line 91: Admin token defaults to "dev" which could be a security risk in production:

RIVET__AUTH__ADMIN_TOKEN: process.env.RIVET__AUTH__ADMIN_TOKEN ?? "dev",

Recommendation: Consider validating that production deployments use proper tokens.


⚡ Performance Considerations

7. File System Operations

  • Multiple file existence checks could be optimized with parallel operations
  • Consider caching version information to reduce I/O

8. Process Management

  • ✅ Good use of stdio: ["inherit", "pipe", "pipe"] for logging
  • ✅ Proper cleanup on process exit
  • ✅ Process reuse logic is well implemented

9. Health Check Implementation (packages/rivetkit/src/engine-process/mod.ts:276-308)

  • Good retry logic with reasonable timeouts (10 seconds)
  • Appropriate interval timing (100ms)
  • ✅ Proper error handling for health check failures

🧪 Test Coverage

Current Tests (packages/rivetkit/tests/engine-process.test.ts)

Only tests resolveTargetTripletFor function (lines 4-38).

Missing Test Coverage

  • Engine binary download logic
  • Process spawning and management
  • Error handling scenarios
  • Platform-specific behavior
  • File system operations
  • Configuration validation
  • Health check functionality

Recommendations:

  1. Add integration tests for engine process lifecycle
  2. Mock file system operations for unit tests
  3. Test error scenarios (network failures, permission issues)
  4. Test process cleanup on various exit conditions

✅ Positive Aspects

  1. Good error handling - Comprehensive error messages and logging throughout
  2. Cross-platform support - Proper platform detection and binary selection
  3. Process lifecycle management - Proper cleanup and PID file management
  4. Configuration flexibility - Good use of environment variables and defaults
  5. Logging practices - Follows repo guidelines with structured logging via logger()
  6. Code organization - Clean separation of concerns and modular design
  7. File permissions - Properly sets executable permissions on Unix systems
  8. Temporary file handling - Safe atomic file operations with temp files

📋 Recommendations

High Priority:

  1. Add binary integrity verification (SHA checksums)
  2. Expand test coverage significantly
  3. Add support for ARM64 Linux architecture
  4. Consider async/await pattern for engine startup

Medium Priority:

  1. Improve error messages with more context
  2. Add configuration validation for production vs development
  3. Consider adding configuration for engine release channels
  4. Add metrics/monitoring for engine process health

Low Priority:

  1. Optimize file system operations
  2. Add JSDoc comments for public APIs
  3. Consider adding retry logic for binary downloads

Overall Assessment

This is a valuable feature that enables automatic engine management, making RivetKit easier to use. The implementation is generally well-structured with good error handling and logging practices. However, it would benefit from:

  1. Expanded test coverage - Critical for ensuring reliability
  2. Security improvements - Binary verification and production token validation
  3. Platform support expansion - ARM64 Linux is increasingly important

Recommendation: ✅ Approve with suggestions - The core functionality is solid and follows repository conventions well.


Copy link

claude bot commented Oct 5, 2025

Claude finished @NathanFlurry's task —— View job


Reviewing PR: feat(core): support running engine

Todo List:

  • Read repository guidelines (CLAUDE.md)
  • Analyze changed files and understand the implementation
  • Review code quality and best practices
  • Check for potential bugs and issues
  • Evaluate performance considerations
  • Assess security concerns
  • Review test coverage
  • Provide comprehensive feedback

Analysis Summary

This PR adds support for running a Rivet engine process automatically within the RivetKit runtime. The implementation includes:

  1. New engine-process module (packages/rivetkit/src/engine-process/mod.ts) - Handles downloading, caching, and spawning the Rivet engine binary
  2. Registry modifications - Adds runEngine configuration option and async process management
  3. Configuration updates - Adds engine version and related settings to run config
  4. Test coverage - Basic tests for platform-specific binary resolution

✅ Positive Aspects

  1. Good error handling - Comprehensive error messages and logging throughout
  2. Cross-platform support - Proper platform detection and binary selection
  3. Process lifecycle management - Proper cleanup and PID file management
  4. Configuration flexibility - Good use of environment variables and defaults
  5. Logging practices - Follows repo guidelines with structured logging via logger()
  6. Code organization - Clean separation of concerns and modular design
  7. File permissions - Properly sets executable permissions on Unix systems
  8. Temporary file handling - Safe atomic file operations with temp files
  9. Health check implementation - Good retry logic with reasonable timeouts (10 seconds)

🐛 Issues and Recommendations

1. Hardcoded Default Values (packages/rivetkit/src/registry/run-config.ts:50)

Line 50: Hardcoded engine version "25.7.3" should be:

  • Documented why this specific version is chosen
  • Consider making it configurable via a constants file
  • Ensure this version is tested and stable

2. Missing Error Context (packages/rivetkit/src/engine-process/mod.ts:176-179)

Lines 176-179: HTTP download error lacks request headers/details that could aid debugging:

throw new Error(
    `failed to download rivet engine binary from ${downloadUrl}: ${response.status} ${response.statusText}`,
);

Recommendation: Include response headers or additional context for debugging network issues.

3. Platform Support Limitations (packages/rivetkit/src/engine-process/mod.ts:234-237)

Lines 234-237: Limited platform support - missing ARM64 Linux and other common architectures:

case "linux":
    if (arch === "x64") {
        return { targetTriplet: "x86_64-unknown-linux-musl", extension: "" };
    }
    break;

Missing: ARM64 Linux support is becoming increasingly important (Apple Silicon, ARM-based cloud instances).

4. Async Engine Startup Race Condition (packages/rivetkit/src/registry/mod.ts:80-85)

The engine process is started asynchronously but actor drivers may start before it's ready:

// Start the engine
const engineProcessPromise = ensureEngineProcess({
    version: config.runEngineVersion,
});

// Chain ready promise
readyPromises.push(engineProcessPromise);

Issue: Actor driver starts in a Promise.all callback (line 170-174), but there's potential for race conditions if other components try to use the engine immediately.


🔒 Security Concerns

5. Binary Download Security (packages/rivetkit/src/engine-process/mod.ts:175-187)

  • Good: Uses HTTPS URL (https://releases.rivet.gg/engine)
  • ⚠️ Missing: No integrity verification (SHA checksum validation)
  • ⚠️ Risk: Downloaded binaries are not verified before execution

Recommendation: Add SHA256 checksum verification for downloaded binaries.

6. Default Admin Token (packages/rivetkit/src/engine-process/mod.ts:90-91)

Lines 90-91: Environment variables are passed through without validation:

env: {
    ...process.env,
},

Recommendation: Consider validating that production deployments use proper authentication tokens.


⚡ Performance Considerations

7. File System Operations

  • Multiple file existence checks could be optimized with parallel operations
  • Consider caching version information to reduce I/O

8. Process Management

  • ✅ Good use of stdio: ["inherit", "pipe", "pipe"] for logging
  • ✅ Proper cleanup on process exit
  • ✅ Process reuse logic is well implemented
  • ✅ Appropriate health check timing (100ms intervals, 10s timeout)

🧪 Test Coverage

Current Tests (packages/rivetkit/tests/engine-process.test.ts)

Only tests resolveTargetTripletFor function (lines 4-38).

Missing Test Coverage

  • Engine binary download logic
  • Process spawning and management
  • Error handling scenarios
  • Platform-specific behavior
  • File system operations
  • Configuration validation
  • Health check functionality

Recommendations:

  1. Add integration tests for engine process lifecycle
  2. Mock file system operations for unit tests
  3. Test error scenarios (network failures, permission issues)
  4. Test process cleanup on various exit conditions

📋 Action Items

High Priority:

  1. Add binary integrity verification (SHA checksums)
  2. Expand test coverage significantly
  3. Add support for ARM64 Linux architecture
  4. Consider documenting the hardcoded engine version choice

Medium Priority:

  1. Improve error messages with more context
  2. Add configuration validation for production vs development
  3. Consider adding configuration for engine release channels
  4. Add metrics/monitoring for engine process health

Low Priority:

  1. Optimize file system operations
  2. Add JSDoc comments for public APIs
  3. Consider adding retry logic for binary downloads

Overall Assessment

This is a valuable feature that enables automatic engine management, making RivetKit easier to use. The implementation is generally well-structured with good error handling and logging practices that follow the repository conventions. The code quality is high and follows the established patterns in the codebase.

The main areas for improvement are:

  1. Security - Binary verification and production token validation
  2. Test coverage - Critical for ensuring reliability across different environments
  3. Platform support - ARM64 Linux is increasingly important

Recommendation: ✅ Approve with suggestions - The core functionality is solid and follows repository conventions well. The suggested improvements would enhance security and reliability but don't block the core feature.


Copy link

claude bot commented Oct 5, 2025

Claude finished @NathanFlurry's task —— View job


Reviewing PR: feat(core): support running engine

Todo List:

  • Read repository guidelines (CLAUDE.md)
  • Analyze changed files and understand the implementation
  • Review code quality and best practices
  • Check for potential bugs and issues
  • Evaluate performance considerations
  • Assess security concerns
  • Review test coverage
  • Provide comprehensive feedback

Analysis Summary

This PR adds support for running a Rivet engine process automatically within the RivetKit runtime. The implementation includes:

  1. New engine-process module (packages/rivetkit/src/engine-process/mod.ts) - Handles downloading, caching, and spawning the Rivet engine binary
  2. Registry modifications - Adds runEngine configuration option and async process management
  3. Configuration updates - Adds engine version and related settings to run config
  4. Test coverage - Basic tests for platform-specific binary resolution
  5. Example updates - Updated counter example to work with engine endpoint

Critical Issues Resolved: The debug code issues from previous reviews have been fixed - file system utilities now work correctly.


🚨 Areas for Improvement

1. Limited Platform Support (packages/rivetkit/src/engine-process/mod.ts:234-243)

Missing ARM64 Linux support:

case "linux":
    if (arch === "x64") {
        return { targetTriplet: "x86_64-unknown-linux-musl", extension: "" };
    }
    break;

Impact: ARM64 Linux is increasingly common (Apple Silicon, ARM cloud instances). Consider adding support for aarch64-unknown-linux-musl.

2. Hardcoded Engine Version (packages/rivetkit/src/registry/run-config.ts:50)

.default(() => getEnvUniversal("RIVET_RUN_ENGINE_VERSION") ?? "25.7.3"),

Recommendation: Document why this specific version is chosen or consider making it more configurable.

3. Missing Binary Integrity Verification (packages/rivetkit/src/engine-process/mod.ts:175-198)

Security concern: Downloaded binaries are not verified before execution.
Recommendation: Add SHA256 checksum verification for downloaded binaries to ensure integrity.


✅ Excellent Implementation Aspects

1. Robust Error Handling & Logging

  • Comprehensive error messages with context throughout
  • Follows repository logging guidelines with structured logging via logger()
  • Proper error propagation and recovery logic

2. Process Lifecycle Management

  • ✅ Proper PID file management and cleanup (packages/rivetkit/src/engine-process/mod.ts:42-67)
  • ✅ Health check implementation with appropriate timeouts (10s) and intervals (100ms)
  • ✅ Graceful process exit handling with log stream cleanup
  • ✅ Process reuse detection to avoid unnecessary restarts

3. Cross-Platform Support

  • Proper platform detection and binary selection
  • Correct file permissions handling (executable on Unix systems)
  • Platform-specific executable extensions

4. Configuration Design

  • Good use of environment variables with sensible defaults
  • Follows zod validation patterns consistently
  • Proper async/promise handling in registry startup

5. Code Organization

  • Clean separation of concerns across modules
  • Follows repository naming conventions (camelCase, PascalCase)
  • Proper TypeScript typing throughout

🔧 Code Quality Assessment

Following Repository Guidelines: ✅ Excellent

  • Proper logging practices (lowercase messages, structured logging)
  • Correct error handling patterns
  • No inappropriate type casting
  • Follows formatting and naming conventions

Performance Considerations: ✅ Good

  • Efficient file operations with proper async handling
  • Smart binary caching to avoid redundant downloads
  • Atomic file operations using temporary files for safety
  • Reasonable health check intervals and timeouts

Security: ⚠️ Good with room for improvement

  • ✅ Uses HTTPS for binary downloads
  • ✅ Proper file permissions on executables
  • ✅ Safe temporary file handling
  • ⚠️ Missing binary integrity verification
  • ⚠️ Default admin token "dev" in development

🧪 Test Coverage Assessment

Current Tests: Basic but focused

  • Tests platform-specific binary resolution logic
  • Covers edge cases (unsupported platform combinations)
  • Uses proper test structure with vitest

Missing Test Areas:

  1. Engine process lifecycle - spawn, health checks, cleanup
  2. Error scenarios - network failures, permission issues, invalid binaries
  3. Configuration validation - various config combinations
  4. File system operations - download, caching, PID management
  5. Integration tests - full engine startup flow

Recommendation: Expand test coverage, especially for error scenarios and process management.


🎯 Recommendations

High Priority

  1. Add ARM64 Linux support - Increasingly important platform
  2. Implement binary integrity verification - Critical for security
  3. Expand test coverage - Focus on process lifecycle and error scenarios

Medium Priority

  1. Improve configuration documentation - Document engine version choice
  2. Enhanced error context - Include more debugging information in network errors
  3. Production token validation - Warn about default tokens in production

Low Priority

  1. Optimize file system operations - Consider parallel operations where safe
  2. Add JSDoc comments - For public APIs in engine-process module

Overall Assessment

This is a well-implemented feature that significantly improves RivetKit's usability by automating engine management. The code follows repository conventions excellently and demonstrates strong engineering practices.

Strengths:

  • Robust process management and error handling
  • Clean, maintainable code organization
  • Good cross-platform support
  • Proper async/await patterns
  • Excellent logging and debugging capabilities

Areas for improvement:

  • Platform support expansion (ARM64 Linux)
  • Security enhancements (binary verification)
  • Test coverage expansion

Recommendation: ✅ Approve - This is quality code that adds valuable functionality. The suggested improvements can be addressed in follow-up PRs.


Comment on lines +73 to +77
invariant(
config.endpoint === undefined,
"cannot specify 'endpoint' with 'runEngine'",
);
config.endpoint = ENGINE_ENDPOINT;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There appears to be contradictory logic in this section. The code first uses invariant() to assert that config.endpoint must be undefined when using runEngine, but then immediately sets config.endpoint = ENGINE_ENDPOINT in the next line.

This creates a confusing flow where the code requires a condition and then immediately changes it. Consider either:

  1. Removing the invariant check since you're setting the endpoint anyway, or
  2. Modifying the check to verify that if config.endpoint is defined, it matches ENGINE_ENDPOINT

For example:

invariant(
  config.endpoint === undefined || config.endpoint === ENGINE_ENDPOINT,
  "When using 'runEngine', 'endpoint' must either be undefined or match the engine endpoint"
);
config.endpoint = ENGINE_ENDPOINT;
Suggested change
invariant(
config.endpoint === undefined,
"cannot specify 'endpoint' with 'runEngine'",
);
config.endpoint = ENGINE_ENDPOINT;
invariant(
config.endpoint === undefined || config.endpoint === ENGINE_ENDPOINT,
"When using 'runEngine', 'endpoint' must either be undefined or match the engine endpoint",
);
config.endpoint = ENGINE_ENDPOINT;

Spotted by Diamond

Fix in Graphite


Is this helpful? React 👍 or 👎 to let us know.

Comment on lines +280 to +296
for (let i = 0; i < maxRetries; i++) {
try {
const response = await fetch(`${ENGINE_ENDPOINT}/health`);
if (response.ok) {
logger().debug({ msg: "engine health check passed" });
return;
}
} catch (error) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current implementation doesn't handle the case where the health check response is not OK but doesn't throw an exception. Consider adding an else clause to handle non-200 responses explicitly:

try {
  const response = await fetch(`${ENGINE_ENDPOINT}/health`);
  if (response.ok) {
    logger().debug({ msg: "engine health check passed" });
    return;
  } else {
    if (i === maxRetries - 1) {
      throw new Error(`engine health check failed after ${maxRetries} retries: HTTP ${response.status}`);
    }
  }
} catch (error) {
  // existing error handling
}

This ensures proper error reporting when the health endpoint returns a non-200 status code.

Suggested change
for (let i = 0; i < maxRetries; i++) {
try {
const response = await fetch(`${ENGINE_ENDPOINT}/health`);
if (response.ok) {
logger().debug({ msg: "engine health check passed" });
return;
}
} catch (error) {
for (let i = 0; i < maxRetries; i++) {
try {
const response = await fetch(`${ENGINE_ENDPOINT}/health`);
if (response.ok) {
logger().debug({ msg: "engine health check passed" });
return;
} else {
if (i === maxRetries - 1) {
throw new Error(`engine health check failed after ${maxRetries} retries: HTTP ${response.status}`);
}
}
} catch (error) {

Spotted by Diamond

Fix in Graphite


Is this helpful? React 👍 or 👎 to let us know.

@NathanFlurry NathanFlurry force-pushed the 10-04-feat_core_support_running_engine branch from fd1d789 to 6c3e109 Compare October 5, 2025 20:55
Copy link

claude bot commented Oct 5, 2025

Claude finished @NathanFlurry's task —— View job


PR Review: feat(core): support running engine

Todo List:

  • Read repository guidelines (CLAUDE.md)
  • Analyze changed files and understand the implementation
  • Review code quality and best practices
  • Check for potential bugs and issues
  • Evaluate performance considerations
  • Assess security concerns
  • Review test coverage
  • Provide comprehensive feedback

Analysis Summary

This PR adds support for running a Rivet engine process automatically within the RivetKit runtime. The implementation includes:

  1. New engine-process module (packages/rivetkit/src/engine-process/mod.ts) - Handles downloading, caching, and spawning the Rivet engine binary
  2. Registry modifications - Adds runEngine configuration option and async process management
  3. Configuration updates - Adds engine version and related settings to run config
  4. Test coverage - Basic tests for platform-specific binary resolution
  5. Example updates - Updated counter example to work with engine endpoint

✅ Excellent Implementation Aspects

Robust Process Management

  • Proper health checks (packages/rivetkit/src/engine-process/mod.ts:284-316) - 10s timeout with 100ms intervals
  • Process reuse detection (packages/rivetkit/src/engine-process/mod.ts:42-59) - Avoids unnecessary restarts
  • Graceful error handling - Comprehensive error messages with context
  • Log stream management (packages/rivetkit/src/engine-process/mod.ts:61-76) - Timestamped log files with proper cleanup

Cross-Platform Support

  • Platform detection (packages/rivetkit/src/engine-process/mod.ts:193-221) - Supports Darwin (ARM64/x64), Linux (x64), Windows (x64)
  • File permissions (packages/rivetkit/src/engine-process/mod.ts:173-175) - Properly sets executable permissions on Unix
  • Atomic file operations (packages/rivetkit/src/engine-process/mod.ts:171-176) - Safe binary downloads using temp files

Code Quality

  • Follows repository guidelines - Uses logger() correctly, lowercase messages, structured logging
  • TypeScript typing - Proper types throughout with good inference
  • Error handling patterns - Follows repository error handling best practices
  • Configuration design - Good use of zod validation and environment variables

🐛 Issues and Recommendations

High Priority

1. Limited Platform Support (packages/rivetkit/src/engine-process/mod.ts:206-210)

Missing ARM64 Linux support:

case "linux":
    if (arch === "x64") {
        return { targetTriplet: "x86_64-unknown-linux-musl", extension: "" };
    }
    break;

Impact: ARM64 Linux is increasingly common (Apple Silicon development, ARM cloud instances). The test at line 35 shows this combination throws an error.

Recommendation: Add support for aarch64-unknown-linux-musl target.

2. Hardcoded Engine Version (packages/rivetkit/src/registry/run-config.ts:50)

.default(() => getEnvUniversal("RIVET_RUN_ENGINE_VERSION") ?? "25.7.3"),

Concerns:

  • No documentation of why this specific version is chosen
  • Could become outdated
  • No validation that this version exists

Recommendation: Consider making this more configurable or document the choice.

Medium Priority

3. Health Check Improvement (packages/rivetkit/src/engine-process/mod.ts:289-303)

The current health check doesn't handle non-200 responses explicitly:

try {
    const response = await fetch(`${ENGINE_ENDPOINT}/health`);
    if (response.ok) {
        // success case
        return;
    }
    // Missing: explicit handling of non-200 responses
} catch (error) {
    // Only catches network errors
}

Recommendation: Add explicit handling for HTTP error responses to improve debugging.

4. Download Error Context (packages/rivetkit/src/engine-process/mod.ts:166-168)

throw new Error(
    `failed to download rivet engine binary from ${downloadUrl}: ${response.status} ${response.statusText}`,
);

Missing: Additional context like response headers could aid in debugging network issues.

Low Priority

5. Invariant Logic (packages/rivetkit/src/registry/mod.ts:73-77)

invariant(
    config.endpoint === undefined,
    "cannot specify 'endpoint' with 'runEngine'",
);
config.endpoint = ENGINE_ENDPOINT;

This pattern feels contradictory - checking that endpoint is undefined, then immediately setting it. Consider allowing either undefined or matching ENGINE_ENDPOINT.


🔒 Security Assessment

Good Security Practices

  • HTTPS downloads - Uses https://releases.rivet.gg/engine for binary downloads
  • Atomic file operations - Safe temporary file handling prevents corruption
  • Process isolation - Proper child process spawning with controlled environment

Areas for Improvement

  • ⚠️ Missing binary integrity verification - Downloaded binaries are not verified with checksums before execution
  • ⚠️ Environment variable passthrough (packages/rivetkit/src/engine-process/mod.ts:81-83) - All process.env passed through without filtering

Recommendation: Consider adding SHA256 checksum verification for downloaded binaries.


⚡ Performance Considerations

Efficient Design

  • Binary caching - Avoids redundant downloads with existence checks
  • Reasonable timeouts - 10s health check timeout with 100ms intervals
  • Async operations - Proper Promise handling in registry startup
  • Process reuse - Smart detection of already-running engines

Optimization Opportunities

  • Could parallelize some file system operations
  • Consider caching platform detection results

🧪 Test Coverage Assessment

Current Coverage (packages/rivetkit/tests/engine-process.test.ts)

  • ✅ Tests resolveTargetTripletFor function with all supported platforms
  • ✅ Tests unsupported platform combinations (ARM64 Linux)
  • ✅ Uses proper vitest structure

Missing Test Areas

  1. Engine process lifecycle - spawn, health checks, cleanup
  2. Error scenarios - network failures, permission issues, invalid binaries
  3. Configuration validation - various config combinations
  4. File system operations - download, caching, directory creation
  5. Integration tests - full engine startup flow
  6. Health check retry logic - timeout and failure scenarios

Recommendation: Expand test coverage, especially for process management and error scenarios. Consider using mocks for external dependencies.


📋 Final Assessment

Strengths

  • Well-engineered solution that significantly improves RivetKit's usability
  • Follows repository conventions excellently (logging, error handling, TypeScript)
  • Robust process management with proper cleanup and health checks
  • Good cross-platform support for major platforms
  • Clean code organization with clear separation of concerns

Areas for Enhancement

  1. Platform support expansion - Add ARM64 Linux support
  2. Security improvements - Binary integrity verification
  3. Test coverage expansion - Process lifecycle and error scenarios
  4. Configuration documentation - Document hardcoded version choice

Recommendation: ✅ Approve with suggestions

This is a high-quality implementation that adds valuable functionality to RivetKit. The code follows repository conventions and demonstrates good engineering practices. The suggested improvements can be addressed in follow-up PRs and don't block the core feature.

Overall Impact: This feature significantly improves the developer experience by automating engine management, making RivetKit easier to set up and use.


@NathanFlurry NathanFlurry changed the base branch from 10-04-fix_next_fix_local_dev to graphite-base/1353 October 5, 2025 21:53
@NathanFlurry NathanFlurry force-pushed the 10-04-feat_core_support_running_engine branch from 6c3e109 to 4fcc430 Compare October 5, 2025 21:53
@NathanFlurry NathanFlurry changed the base branch from graphite-base/1353 to 10-04-fix_example-deno_fix_check-types October 5, 2025 21:53
Copy link

claude bot commented Oct 5, 2025

Claude finished @NathanFlurry's task —— View job


Reviewing PR: feat(core): support running engine

Todo List:

  • Read repository guidelines (CLAUDE.md)
  • Analyze changed files and understand the implementation
  • Review code quality and best practices
  • Check for potential bugs and issues
  • Evaluate performance considerations
  • Assess security concerns
  • Review test coverage
  • Provide comprehensive feedback

Analysis Summary

This PR adds support for running a Rivet engine process automatically within the RivetKit runtime. The implementation includes:

  1. New engine-process module (packages/rivetkit/src/engine-process/mod.ts) - Handles downloading, caching, and spawning the Rivet engine binary
  2. Registry modifications - Adds runEngine configuration option and async process management
  3. Configuration updates - Adds engine version and related settings to run config
  4. Test coverage - Basic tests for platform-specific binary resolution
  5. Example updates - Updated counter example to work with engine endpoint

✅ Excellent Implementation Aspects

Robust Process Management

  • Proper health checks (packages/rivetkit/src/engine-process/mod.ts:284-316) - 10s timeout with 100ms intervals
  • Process reuse detection (packages/rivetkit/src/engine-process/mod.ts:42-59) - Avoids unnecessary restarts
  • Graceful error handling - Comprehensive error messages with context
  • Log stream management (packages/rivetkit/src/engine-process/mod.ts:61-76) - Timestamped log files with proper cleanup

Cross-Platform Support

  • Platform detection (packages/rivetkit/src/engine-process/mod.ts:193-221) - Supports Darwin (ARM64/x64), Linux (x64), Windows (x64)
  • File permissions (packages/rivetkit/src/engine-process/mod.ts:173-175) - Properly sets executable permissions on Unix
  • Atomic file operations (packages/rivetkit/src/engine-process/mod.ts:171-176) - Safe binary downloads using temp files

Code Quality

  • Follows repository guidelines - Uses logger() correctly, lowercase messages, structured logging
  • TypeScript typing - Proper types throughout with good inference
  • Error handling patterns - Follows repository error handling best practices
  • Configuration design - Good use of zod validation and environment variables

🐛 Issues and Recommendations

High Priority

1. Limited Platform Support (packages/rivetkit/src/engine-process/mod.ts:206-210)

Missing ARM64 Linux support:

case "linux":
    if (arch === "x64") {
        return { targetTriplet: "x86_64-unknown-linux-musl", extension: "" };
    }
    break;

Impact: ARM64 Linux is increasingly common (Apple Silicon development, ARM cloud instances). The test at line 35 shows this combination throws an error.

Recommendation: Add support for aarch64-unknown-linux-musl target.

2. Hardcoded Engine Version (packages/rivetkit/src/registry/run-config.ts:50)

.default(() => getEnvUniversal("RIVET_RUN_ENGINE_VERSION") ?? "25.7.3"),

Concerns:

  • No documentation of why this specific version is chosen
  • Could become outdated
  • No validation that this version exists

Recommendation: Consider making this more configurable or document the choice.

Medium Priority

3. Health Check Improvement (packages/rivetkit/src/engine-process/mod.ts:289-303)

The current health check doesn't handle non-200 responses explicitly:

try {
    const response = await fetch(`${ENGINE_ENDPOINT}/health`);
    if (response.ok) {
        // success case
        return;
    }
    // Missing: explicit handling of non-200 responses
} catch (error) {
    // Only catches network errors
}

Recommendation: Add explicit handling for HTTP error responses to improve debugging.

4. Download Error Context (packages/rivetkit/src/engine-process/mod.ts:166-168)

throw new Error(
    `failed to download rivet engine binary from ${downloadUrl}: ${response.status} ${response.statusText}`,
);

Missing: Additional context like response headers could aid in debugging network issues.

Low Priority

5. Invariant Logic (packages/rivetkit/src/registry/mod.ts:73-77)

invariant(
    config.endpoint === undefined,
    "cannot specify 'endpoint' with 'runEngine'",
);
config.endpoint = ENGINE_ENDPOINT;

This pattern feels contradictory - checking that endpoint is undefined, then immediately setting it. Consider allowing either undefined or matching ENGINE_ENDPOINT.


🔒 Security Assessment

Good Security Practices

  • HTTPS downloads - Uses https://releases.rivet.gg/engine for binary downloads
  • Atomic file operations - Safe temporary file handling prevents corruption
  • Process isolation - Proper child process spawning with controlled environment

Areas for Improvement

  • ⚠️ Missing binary integrity verification - Downloaded binaries are not verified with checksums before execution
  • ⚠️ Environment variable passthrough (packages/rivetkit/src/engine-process/mod.ts:81-83) - All process.env passed through without filtering

Recommendation: Consider adding SHA256 checksum verification for downloaded binaries.


⚡ Performance Considerations

Efficient Design

  • Binary caching - Avoids redundant downloads with existence checks
  • Reasonable timeouts - 10s health check timeout with 100ms intervals
  • Async operations - Proper Promise handling in registry startup
  • Process reuse - Smart detection of already-running engines

Optimization Opportunities

  • Could parallelize some file system operations
  • Consider caching platform detection results

🧪 Test Coverage Assessment

Current Coverage (packages/rivetkit/tests/engine-process.test.ts)

  • ✅ Tests resolveTargetTripletFor function with all supported platforms
  • ✅ Tests unsupported platform combinations (ARM64 Linux)
  • ✅ Uses proper vitest structure

Missing Test Areas

  1. Engine process lifecycle - spawn, health checks, cleanup
  2. Error scenarios - network failures, permission issues, invalid binaries
  3. Configuration validation - various config combinations
  4. File system operations - download, caching, directory creation
  5. Integration tests - full engine startup flow
  6. Health check retry logic - timeout and failure scenarios

Recommendation: Expand test coverage, especially for process management and error scenarios. Consider using mocks for external dependencies.


📋 Final Assessment

Strengths

  • Well-engineered solution that significantly improves RivetKit's usability
  • Follows repository conventions excellently (logging, error handling, TypeScript)
  • Robust process management with proper cleanup and health checks
  • Good cross-platform support for major platforms
  • Clean code organization with clear separation of concerns

Areas for Enhancement

  1. Platform support expansion - Add ARM64 Linux support
  2. Security improvements - Binary integrity verification
  3. Test coverage expansion - Process lifecycle and error scenarios
  4. Configuration documentation - Document hardcoded version choice

Recommendation: ✅ Approve with suggestions

This is a high-quality implementation that adds valuable functionality to RivetKit. The code follows repository conventions and demonstrates good engineering practices. The suggested improvements can be addressed in follow-up PRs and don't block the core feature.

Overall Impact: This feature significantly improves the developer experience by automating engine management, making RivetKit easier to set up and use.


Copy link

claude bot commented Oct 5, 2025

Claude finished @NathanFlurry's task —— View job


Reviewing PR: feat(core): support running engine

Todo List:

  • Read repository guidelines (CLAUDE.md)
  • Analyze changed files and understand the implementation
  • Review code quality and best practices
  • Check for potential bugs and issues
  • Evaluate performance considerations
  • Assess security concerns
  • Review test coverage
  • Provide comprehensive feedback

Analysis Summary

This PR adds support for running a Rivet engine process automatically within the RivetKit runtime. The implementation includes:

  1. New engine-process module (packages/rivetkit/src/engine-process/mod.ts) - Handles downloading, caching, and spawning the Rivet engine binary
  2. Registry modifications - Adds runEngine configuration option and async process management
  3. Configuration updates - Adds engine version and related settings to run config
  4. Test coverage - Basic tests for platform-specific binary resolution
  5. Example updates - Updated counter example to work with engine endpoint

✅ Excellent Implementation Aspects

Robust Process Management

  • Proper health checks (packages/rivetkit/src/engine-process/mod.ts:284-316) - 10s timeout with 100ms intervals
  • Process reuse detection (packages/rivetkit/src/engine-process/mod.ts:42-59) - Avoids unnecessary restarts
  • Graceful error handling - Comprehensive error messages with context
  • Log stream management (packages/rivetkit/src/engine-process/mod.ts:61-76) - Timestamped log files with proper cleanup

Cross-Platform Support

  • Platform detection (packages/rivetkit/src/engine-process/mod.ts:193-221) - Supports Darwin (ARM64/x64), Linux (x64), Windows (x64)
  • File permissions (packages/rivetkit/src/engine-process/mod.ts:173-175) - Properly sets executable permissions on Unix
  • Atomic file operations (packages/rivetkit/src/engine-process/mod.ts:171-176) - Safe binary downloads using temp files

Code Quality

  • Follows repository guidelines - Uses logger() correctly, lowercase messages, structured logging
  • TypeScript typing - Proper types throughout with good inference
  • Error handling patterns - Follows repository error handling best practices
  • Configuration design - Good use of zod validation and environment variables

🐛 Issues and Recommendations

High Priority

1. Limited Platform Support (packages/rivetkit/src/engine-process/mod.ts:206-210)

Missing ARM64 Linux support:

case "linux":
    if (arch === "x64") {
        return { targetTriplet: "x86_64-unknown-linux-musl", extension: "" };
    }
    break;

Impact: ARM64 Linux is increasingly common (Apple Silicon development, ARM cloud instances). The test at line 35 shows this combination throws an error.

Recommendation: Add support for aarch64-unknown-linux-musl target.

2. Hardcoded Engine Version (packages/rivetkit/src/registry/run-config.ts:50)

.default(() => getEnvUniversal("RIVET_RUN_ENGINE_VERSION") ?? "25.7.3"),

Concerns:

  • No documentation of why this specific version is chosen
  • Could become outdated
  • No validation that this version exists

Recommendation: Consider making this more configurable or document the choice.

Medium Priority

3. Health Check Improvement (packages/rivetkit/src/engine-process/mod.ts:289-303)

The current health check doesn't handle non-200 responses explicitly:

try {
    const response = await fetch(`${ENGINE_ENDPOINT}/health`);
    if (response.ok) {
        // success case
        return;
    }
    // Missing: explicit handling of non-200 responses
} catch (error) {
    // Only catches network errors
}

Recommendation: Add explicit handling for HTTP error responses to improve debugging.

4. Download Error Context (packages/rivetkit/src/engine-process/mod.ts:166-168)

throw new Error(
    `failed to download rivet engine binary from ${downloadUrl}: ${response.status} ${response.statusText}`,
);

Missing: Additional context like response headers could aid in debugging network issues.

Low Priority

5. Invariant Logic (packages/rivetkit/src/registry/mod.ts:73-77)

invariant(
    config.endpoint === undefined,
    "cannot specify 'endpoint' with 'runEngine'",
);
config.endpoint = ENGINE_ENDPOINT;

This pattern feels contradictory - checking that endpoint is undefined, then immediately setting it. Consider allowing either undefined or matching ENGINE_ENDPOINT.


🔒 Security Assessment

Good Security Practices

  • HTTPS downloads - Uses https://releases.rivet.gg/engine for binary downloads
  • Atomic file operations - Safe temporary file handling prevents corruption
  • Process isolation - Proper child process spawning with controlled environment

Areas for Improvement

  • ⚠️ Missing binary integrity verification - Downloaded binaries are not verified with checksums before execution
  • ⚠️ Environment variable passthrough (packages/rivetkit/src/engine-process/mod.ts:81-83) - All process.env passed through without filtering

Recommendation: Consider adding SHA256 checksum verification for downloaded binaries.


⚡ Performance Considerations

Efficient Design

  • Binary caching - Avoids redundant downloads with existence checks
  • Reasonable timeouts - 10s health check timeout with 100ms intervals
  • Async operations - Proper Promise handling in registry startup
  • Process reuse - Smart detection of already-running engines

Optimization Opportunities

  • Could parallelize some file system operations
  • Consider caching platform detection results

🧪 Test Coverage Assessment

Current Coverage (packages/rivetkit/tests/engine-process.test.ts)

  • ✅ Tests resolveTargetTripletFor function with all supported platforms
  • ✅ Tests unsupported platform combinations (ARM64 Linux)
  • ✅ Uses proper vitest structure

Missing Test Areas

  1. Engine process lifecycle - spawn, health checks, cleanup
  2. Error scenarios - network failures, permission issues, invalid binaries
  3. Configuration validation - various config combinations
  4. File system operations - download, caching, directory creation
  5. Integration tests - full engine startup flow
  6. Health check retry logic - timeout and failure scenarios

Recommendation: Expand test coverage, especially for process management and error scenarios. Consider using mocks for external dependencies.


📋 Final Assessment

Strengths

  • Well-engineered solution that significantly improves RivetKit's usability
  • Follows repository conventions excellently (logging, error handling, TypeScript)
  • Robust process management with proper cleanup and health checks
  • Good cross-platform support for major platforms
  • Clean code organization with clear separation of concerns

Areas for Enhancement

  1. Platform support expansion - Add ARM64 Linux support
  2. Security improvements - Binary integrity verification
  3. Test coverage expansion - Process lifecycle and error scenarios
  4. Configuration documentation - Document hardcoded version choice

Recommendation: ✅ Approve with suggestions

This is a high-quality implementation that adds valuable functionality to RivetKit. The code follows repository conventions and demonstrates good engineering practices. The suggested improvements can be addressed in follow-up PRs and don't block the core feature.

Overall Impact: This feature significantly improves the developer experience by automating engine management, making RivetKit easier to set up and use.


Copy link

graphite-app bot commented Oct 6, 2025

Merge activity

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

graphite-app bot pushed a commit that referenced this pull request Oct 6, 2025
@graphite-app graphite-app bot closed this Oct 6, 2025
@graphite-app graphite-app bot deleted the 10-04-feat_core_support_running_engine branch October 6, 2025 19:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant