fix: get new actors working on docker compose

[MasterPtato]

Changes

[MasterPtato]

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

• fix: get pb manager test working e2e again #2721
• fix: convert runner protocol to protobuf #2702
• fix: even more actor api changes #2714
• chore: flatten actor api spec #2698
• fix: increase default actor kill timeout to 5s #2701
• fix: dont clear ingress ports on reschedule #2700
• fix: add cpu constraints to oci config #2697
• fix: api changes #2692
• fix: fix logs for new actors #2649
• feat: add actor queue #2644
• feat: add actor kv to runners #2638
• feat: get multi actors working e2e on docker compose #2637
• fix: add udp ports to docker compose #2635
• chore: fix merge conflicts #2634
• fix: get new actors working on docker compose #2623 👈 (View in Graphite)
• fix: figure out actor log shipping #2622
• fix(pegboard): convert ws manager socket to unix socket #2478
• fix(pb): get new actor ids working e2e #2471
• feat: implement new actor ids #2467
• feat(pb): get multi-actors working e2e, add resources for builds #2465
• feat(pb): add runner logs #2447
• feat: add runners to pb protocol #2433
• chore(pegboard): add exit code log from container runner #2477
• fix(workflows): fix branch version bug #2475
• chore(pegboard): replace computing image size manually with using tar bytes read #2625
• fix: make pb image downloads random, remove prewarm from pb protocol #2784
• fix: clean up worker threads in the event of an error #2783
• fix: make query_as macros retry #2773
• 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.

[cloudflare-workers-and-pages]

Deploying rivet with    Cloudflare Pages

Latest commit:	d916410
Status:	🚫  Build failed.

View logs

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: Fix new actors working on docker compose

Reviewing this PR for code quality, potential bugs, performance, security, and test coverage.

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze core Rust changes in packages/edge/
• Review database migrations
• Check Docker and configuration changes
• Examine test modifications
• Provide comprehensive feedback on code quality
• Identify potential bugs and issues
• Assess performance considerations
• Review security implications
• Evaluate test coverage

---

Review Summary

This PR implements significant changes to support "new actors" with enhanced ID management and Docker Compose compatibility. Overall the changes are well-structured, but there are several issues that need attention.

🐛 Critical Issues

1. Build Error in container-runner (packages/edge/infra/client/container-runner/src/main.rs:61)

   let exit_code = match container::run(
       msg_tx.clone(),
       &actor_path,  // ❌ `actor_path` is undefined
       &container_id,
       root_user_enabled,
   )

   Should likely be runner_path instead of actor_path.

2. Tokio async block issue (Already identified by graphite-app at packages/edge/infra/client/manager/src/main.rs:193)

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into)? },  // ❌ Incorrect ? usage

   Should be:

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into) },

⚠️ Potential Issues

1. Database Migration Concerns

   • add_runner_id.up.sql adds a column but no down migration provided for reversibility
   • No indices defined for the new runner_id column which could impact query performance

2. Memory Management in Runtime (packages/edge/services/pegboard/src/workflows/actor2/runtime.rs)

   • Complex FDB transaction logic with multiple memory calculations could benefit from better error handling for edge cases
   • Large transaction bodies (500+ lines) might hit FDB transaction limits under high contention

3. Resource Allocation Logic

   • Bin-packing algorithm in allocate_actor could lead to memory fragmentation over time
   • No apparent cleanup for stale allocation records

🔒 Security Considerations

1. Unsafe Code (packages/common/util/id/src/lib.rs:204)

   let s = unsafe { String::from_utf8_unchecked(buf.to_vec()) };

   While documented as safe (ASCII), consider using safe conversion for defense in depth.

2. Environment Variable Handling

   • Container runner accepts ROOT_USER_ENABLED and VECTOR_SOCKET_ADDR - ensure these are properly validated in production environments

⚡ Performance Considerations

1. Efficient Improvements

   • New ID system with V1 format (30-char base36) is more efficient than UUIDs for certain use cases
   • FDB snapshot reads reduce transaction conflicts in allocation logic

2. Areas for Optimization

   • ClickHouse actor_runners table could benefit from better partitioning strategy
   • Vector message serialization in log_shipper happens per message - consider batching

🧪 Test Coverage

1. Positive Changes

   • TypeScript test includes both HTTP and UDP protocol testing
   • Test covers actor lifecycle (create → ready → destroy)

2. Missing Coverage

   • No integration tests for new actor allocation algorithm
   • FDB transaction rollback scenarios not covered
   • Error handling paths in log shipping not tested

📋 Code Quality

Good Practices:

• Comprehensive error handling with proper context
• Well-structured workflow pattern with state management
• Clear separation of concerns (allocation, runtime, destruction)

Areas for Improvement:

• Some functions are quite large (e.g., allocate_actor at 200+ lines)
• Magic numbers could be better documented (e.g., ACTOR_START_THRESHOLD_MS)
• Missing documentation for complex allocation algorithm

🐳 Docker & Configuration

• Docker builds correctly include all new binaries
• Configuration changes are minimal and focused
• Multi-stage build properly optimized

---

Recommendations

1. Fix the critical build error in container-runner/main.rs
2. Address the tokio async block issue as suggested by graphite-app
3. Add database migration rollback for the runner_id column
4. Consider adding integration tests for the new allocation logic
5. Document the allocation algorithm for future maintainers

The overall approach is sound and the implementation follows good patterns. Once the critical issues are addressed, this should be ready for merge.

---

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: Fix new actors working on docker compose

Reviewing this PR for code quality, potential bugs, performance, security, and test coverage.

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze core Rust changes in packages/edge/
• Review database migrations
• Check Docker and configuration changes
• Examine test modifications
• Provide comprehensive feedback on code quality
• Identify potential bugs and issues
• Assess performance considerations
• Review security implications
• Evaluate test coverage

---

Review Summary

This PR implements significant changes to support "new actors" with enhanced ID management and Docker Compose compatibility. Overall the changes are well-structured, but there are several issues that need attention.

🐛 Critical Issues

1. Build Error in container-runner (packages/edge/infra/client/container-runner/src/main.rs:61)

   let exit_code = match container::run(
       msg_tx.clone(),
       &actor_path,  // ❌ `actor_path` is undefined
       &container_id,
       root_user_enabled,
   )

   Should likely be runner_path instead of actor_path.

2. Tokio async block issue (Already identified by graphite-app at packages/edge/infra/client/manager/src/main.rs:193)

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into)? },  // ❌ Incorrect ? usage

   Should be:

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into) },

⚠️ Potential Issues

1. Database Migration Concerns

   • add_runner_id.up.sql adds a column but no down migration provided for reversibility
   • No indices defined for the new runner_id column which could impact query performance

2. Memory Management in Runtime (packages/edge/services/pegboard/src/workflows/actor2/runtime.rs)

   • Complex FDB transaction logic with multiple memory calculations could benefit from better error handling for edge cases
   • Large transaction bodies (500+ lines) might hit FDB transaction limits under high contention

3. Resource Allocation Logic

   • Bin-packing algorithm in allocate_actor could lead to memory fragmentation over time
   • No apparent cleanup for stale allocation records

🔒 Security Considerations

1. Unsafe Code (packages/common/util/id/src/lib.rs:204)

   let s = unsafe { String::from_utf8_unchecked(buf.to_vec()) };

   While documented as safe (ASCII), consider using safe conversion for defense in depth.

2. Environment Variable Handling

   • Container runner accepts ROOT_USER_ENABLED and VECTOR_SOCKET_ADDR - ensure these are properly validated in production environments

⚡ Performance Considerations

1. Efficient Improvements

   • New ID system with V1 format (30-char base36) is more efficient than UUIDs for certain use cases
   • FDB snapshot reads reduce transaction conflicts in allocation logic

2. Areas for Optimization

   • ClickHouse actor_runners table could benefit from better partitioning strategy
   • Vector message serialization in log_shipper happens per message - consider batching

🧪 Test Coverage

1. Positive Changes

   • TypeScript test includes both HTTP and UDP protocol testing
   • Test covers actor lifecycle (create → ready → destroy)

2. Missing Coverage

   • No integration tests for new actor allocation algorithm
   • FDB transaction rollback scenarios not covered
   • Error handling paths in log shipping not tested

📋 Code Quality

Good Practices:

• Comprehensive error handling with proper context
• Well-structured workflow pattern with state management
• Clear separation of concerns (allocation, runtime, destruction)

Areas for Improvement:

• Some functions are quite large (e.g., allocate_actor at 200+ lines)
• Magic numbers could be better documented (e.g., ACTOR_START_THRESHOLD_MS)
• Missing documentation for complex allocation algorithm

🐳 Docker & Configuration

• Docker builds correctly include all new binaries
• Configuration changes are minimal and focused
• Multi-stage build properly optimized

---

Recommendations

1. Fix the critical build error in container-runner/main.rs
2. Address the tokio async block issue as suggested by graphite-app
3. Add database migration rollback for the runner_id column
4. Consider adding integration tests for the new allocation logic
5. Document the allocation algorithm for future maintainers

The overall approach is sound and the implementation follows good patterns. Once the critical issues are addressed, this should be ready for merge.

---

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: Fix new actors working on docker compose

Reviewing this PR for code quality, potential bugs, performance, security, and test coverage.

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze core Rust changes in packages/edge/
• Review database migrations
• Check Docker and configuration changes
• Examine test modifications
• Provide comprehensive feedback on code quality
• Identify potential bugs and issues
• Assess performance considerations
• Review security implications
• Evaluate test coverage

---

Review Summary

This PR implements significant changes to support "new actors" with enhanced ID management and Docker Compose compatibility. Overall the changes are well-structured, but there are several issues that need attention.

🐛 Critical Issues

1. Build Error in container-runner (packages/edge/infra/client/container-runner/src/main.rs:61)

   let exit_code = match container::run(
       msg_tx.clone(),
       &actor_path,  // ❌ `actor_path` is undefined
       &container_id,
       root_user_enabled,
   )

   Should likely be runner_path instead of actor_path.

2. Tokio async block issue (Already identified by graphite-app at packages/edge/infra/client/manager/src/main.rs:193)

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into)? },  // ❌ Incorrect ? usage

   Should be:

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into) },

⚠️ Potential Issues

1. Database Migration Concerns

   • add_runner_id.up.sql adds a column but no down migration provided for reversibility
   • No indices defined for the new runner_id column which could impact query performance

2. Memory Management in Runtime (packages/edge/services/pegboard/src/workflows/actor2/runtime.rs)

   • Complex FDB transaction logic with multiple memory calculations could benefit from better error handling for edge cases
   • Large transaction bodies (500+ lines) might hit FDB transaction limits under high contention

3. Resource Allocation Logic

   • Bin-packing algorithm in allocate_actor could lead to memory fragmentation over time
   • No apparent cleanup for stale allocation records

🔒 Security Considerations

1. Unsafe Code (packages/common/util/id/src/lib.rs:204)

   let s = unsafe { String::from_utf8_unchecked(buf.to_vec()) };

   While documented as safe (ASCII), consider using safe conversion for defense in depth.

2. Environment Variable Handling

   • Container runner accepts ROOT_USER_ENABLED and VECTOR_SOCKET_ADDR - ensure these are properly validated in production environments

⚡ Performance Considerations

1. Efficient Improvements

   • New ID system with V1 format (30-char base36) is more efficient than UUIDs for certain use cases
   • FDB snapshot reads reduce transaction conflicts in allocation logic

2. Areas for Optimization

   • ClickHouse actor_runners table could benefit from better partitioning strategy
   • Vector message serialization in log_shipper happens per message - consider batching

🧪 Test Coverage

1. Positive Changes

   • TypeScript test includes both HTTP and UDP protocol testing
   • Test covers actor lifecycle (create → ready → destroy)

2. Missing Coverage

   • No integration tests for new actor allocation algorithm
   • FDB transaction rollback scenarios not covered
   • Error handling paths in log shipping not tested

📋 Code Quality

Good Practices:

• Comprehensive error handling with proper context
• Well-structured workflow pattern with state management
• Clear separation of concerns (allocation, runtime, destruction)

Areas for Improvement:

• Some functions are quite large (e.g., allocate_actor at 200+ lines)
• Magic numbers could be better documented (e.g., ACTOR_START_THRESHOLD_MS)
• Missing documentation for complex allocation algorithm

🐳 Docker & Configuration

• Docker builds correctly include all new binaries
• Configuration changes are minimal and focused
• Multi-stage build properly optimized

---

Recommendations

1. Fix the critical build error in container-runner/main.rs
2. Address the tokio async block issue as suggested by graphite-app
3. Add database migration rollback for the runner_id column
4. Consider adding integration tests for the new allocation logic
5. Document the allocation algorithm for future maintainers

The overall approach is sound and the implementation follows good patterns. Once the critical issues are addressed, this should be ready for merge.

---

View job

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: Fix new actors working on docker compose

Reviewing this PR for code quality, potential bugs, performance, security, and test coverage.

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze core Rust changes in packages/edge/
• Review database migrations
• Check Docker and configuration changes
• Examine test modifications
• Provide comprehensive feedback on code quality
• Identify potential bugs and issues
• Assess performance considerations
• Review security implications
• Evaluate test coverage

---

Review Summary

This PR implements significant changes to support "new actors" with enhanced ID management and Docker Compose compatibility. Overall the changes are well-structured, but there are several issues that need attention.

🐛 Critical Issues

1. Build Error in container-runner (packages/edge/infra/client/container-runner/src/main.rs:65)

   let exit_code = match container::run(
       msg_tx.clone(),
       &actor_path,  // ❌ `actor_path` is undefined
       &container_id,
       root_user_enabled,
   )

   Should likely be runner_path instead of actor_path.

2. Tokio async block issue (Already identified by graphite-app at packages/edge/infra/client/manager/src/main.rs:193)

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into)? },  // ❌ Incorrect ? usage

   Should be:

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into) },

⚠️ Potential Issues

1. Database Migration Concerns

   • add_runner_id.up.sql adds a column but no down migration provided for reversibility
   • No indices defined for the new runner_id column which could impact query performance

2. Memory Management in Runtime (packages/edge/services/pegboard/src/workflows/actor2/runtime.rs)

   • Complex FDB transaction logic with multiple memory calculations could benefit from better error handling for edge cases
   • Large transaction bodies (500+ lines) might hit FDB transaction limits under high contention

3. Resource Allocation Logic

   • Bin-packing algorithm in allocate_actor could lead to memory fragmentation over time
   • No apparent cleanup for stale allocation records

🔒 Security Considerations

1. Unsafe Code (packages/common/util/id/src/lib.rs:204)

   let s = unsafe { String::from_utf8_unchecked(buf.to_vec()) };

   While documented as safe (ASCII), consider using safe conversion for defense in depth.

2. Environment Variable Handling

   • Container runner accepts ROOT_USER_ENABLED and VECTOR_SOCKET_ADDR - ensure these are properly validated in production environments

⚡ Performance Considerations

1. Efficient Improvements

   • New ID system with V1 format (30-char base36) is more efficient than UUIDs for certain use cases
   • FDB snapshot reads reduce transaction conflicts in allocation logic

2. Areas for Optimization

   • ClickHouse actor_runners table could benefit from better partitioning strategy
   • Vector message serialization in log_shipper happens per message - consider batching

🧪 Test Coverage

1. Positive Changes

   • TypeScript test includes both HTTP and UDP protocol testing
   • Test covers actor lifecycle (create → ready → destroy)

2. Missing Coverage

   • No integration tests for new actor allocation algorithm
   • FDB transaction rollback scenarios not covered
   • Error handling paths in log shipping not tested

📋 Code Quality

Good Practices:

• Comprehensive error handling with proper context
• Well-structured workflow pattern with state management
• Clear separation of concerns (allocation, runtime, destruction)

Areas for Improvement:

• Some functions are quite large (e.g., allocate_actor at 200+ lines)
• Magic numbers could be better documented (e.g., ACTOR_START_THRESHOLD_MS)
• Missing documentation for complex allocation algorithm

🐳 Docker & Configuration

• Docker builds correctly include all new binaries
• Configuration changes are minimal and focused
• Multi-stage build properly optimized

---

Recommendations

1. Fix the critical build error in container-runner/main.rs
2. Address the tokio async block issue as suggested by graphite-app
3. Add database migration rollback for the runner_id column
4. Consider adding integration tests for the new allocation logic
5. Document the allocation algorithm for future maintainers

The overall approach is sound and the implementation follows good patterns. Once the critical issues are addressed, this should be ready for merge.

---

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: Fix new actors working on docker compose

Reviewing this PR for code quality, potential bugs, performance, security, and test coverage.

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze core Rust changes in packages/edge/
• Review database migrations
• Check Docker and configuration changes
• Examine test modifications
• Provide comprehensive feedback on code quality
• Identify potential bugs and issues
• Assess performance considerations
• Review security implications
• Evaluate test coverage

---

Review Summary

This PR implements significant changes to support "new actors" with enhanced ID management and Docker Compose compatibility. Overall the changes are well-structured, but there are several issues that need attention.

🐛 Critical Issues

1. Build Error in container-runner (packages/edge/infra/client/container-runner/src/main.rs:65)

   let exit_code = match container::run(
       msg_tx.clone(),
       &actor_path,  // ❌ `actor_path` is undefined
       &container_id,
       root_user_enabled,
   )

   Should likely be runner_path instead of actor_path.

2. Tokio async block issue (Already identified by graphite-app at packages/edge/infra/client/manager/src/main.rs:193)

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into)? },  // ❌ Incorrect ? usage

   Should be:

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into) },

⚠️ Potential Issues

1. Database Migration Concerns

   • add_runner_id.up.sql adds a column but no down migration provided for reversibility
   • No indices defined for the new runner_id column which could impact query performance

2. Memory Management in Runtime (packages/edge/services/pegboard/src/workflows/actor2/runtime.rs)

   • Complex FDB transaction logic with multiple memory calculations could benefit from better error handling for edge cases
   • Large transaction bodies (500+ lines) might hit FDB transaction limits under high contention

3. Resource Allocation Logic

   • Bin-packing algorithm in allocate_actor could lead to memory fragmentation over time
   • No apparent cleanup for stale allocation records

🔒 Security Considerations

1. Unsafe Code (packages/common/util/id/src/lib.rs:204)

   let s = unsafe { String::from_utf8_unchecked(buf.to_vec()) };

   While documented as safe (ASCII), consider using safe conversion for defense in depth.

2. Environment Variable Handling

   • Container runner accepts ROOT_USER_ENABLED and VECTOR_SOCKET_ADDR - ensure these are properly validated in production environments

⚡ Performance Considerations

1. Efficient Improvements

   • New ID system with V1 format (30-char base36) is more efficient than UUIDs for certain use cases
   • FDB snapshot reads reduce transaction conflicts in allocation logic

2. Areas for Optimization

   • ClickHouse actor_runners table could benefit from better partitioning strategy
   • Vector message serialization in log_shipper happens per message - consider batching

🧪 Test Coverage

1. Positive Changes

   • TypeScript test includes both HTTP and UDP protocol testing
   • Test covers actor lifecycle (create → ready → destroy)

2. Missing Coverage

   • No integration tests for new actor allocation algorithm
   • FDB transaction rollback scenarios not covered
   • Error handling paths in log shipping not tested

📋 Code Quality

Good Practices:

• Comprehensive error handling with proper context
• Well-structured workflow pattern with state management
• Clear separation of concerns (allocation, runtime, destruction)

Areas for Improvement:

• Some functions are quite large (e.g., allocate_actor at 200+ lines)
• Magic numbers could be better documented (e.g., ACTOR_START_THRESHOLD_MS)
• Missing documentation for complex allocation algorithm

🐳 Docker & Configuration

• Docker builds correctly include all new binaries
• Configuration changes are minimal and focused
• Multi-stage build properly optimized

---

Recommendations

1. Fix the critical build error in container-runner/main.rs
2. Address the tokio async block issue as suggested by graphite-app
3. Add database migration rollback for the runner_id column
4. Consider adding integration tests for the new allocation logic
5. Document the allocation algorithm for future maintainers

The overall approach is sound and the implementation follows good patterns. Once the critical issues are addressed, this should be ready for merge.

---

[graphite-app]

The error handling here is incomplete. When awaiting a JoinHandle, you get a Result<T, JoinError> where T is the task's result (which is already an anyhow::Error). The current ? only handles the JoinError but not the inner error.

Consider either:

async { 
    // Handle both the JoinError and the inner anyhow::Error
    metrics_task.await.map_err(Into::<anyhow::Error>::into)?? 
}

Or a more explicit approach:

async {
    let result = metrics_task.await.map_err(Into::<anyhow::Error>::into)?;
    result
}

This ensures both the task completion error and any error returned by the metrics task itself are properly propagated.

Suggested change

	async { metrics_task.await.map_err(Into::<anyhow::Error>::into)? },
	async { metrics_task.await.map_err(Into::<anyhow::Error>::into)?? },

Spotted by Diamond

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

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: Fix new actors working on docker compose

Reviewing this PR for code quality, potential bugs, performance, security, and test coverage.

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze core Rust changes in packages/edge/
• Review database migrations
• Check Docker and configuration changes
• Examine test modifications
• Provide comprehensive feedback on code quality
• Identify potential bugs and issues
• Assess performance considerations
• Review security implications
• Evaluate test coverage

---

Review Summary

This PR implements significant changes to support "new actors" with enhanced ID management and Docker Compose compatibility. Overall the changes are well-structured, but there are several issues that need attention.

🐛 Critical Issues

1. Build Error in container-runner (packages/edge/infra/client/container-runner/src/main.rs:65)

   let exit_code = match container::run(
       msg_tx.clone(),
       &actor_path,  // ❌ `actor_path` is undefined
       &container_id,
       root_user_enabled,
   )

   Should likely be runner_path instead of actor_path.

2. Tokio async block issue (Already identified by graphite-app at packages/edge/infra/client/manager/src/main.rs:193)

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into)? },  // ❌ Incorrect ? usage

   Should be:

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into) },

⚠️ Potential Issues

1. Database Migration Concerns

   • add_runner_id.up.sql adds a column but no down migration provided for reversibility
   • No indices defined for the new runner_id column which could impact query performance

2. Memory Management in Runtime (packages/edge/services/pegboard/src/workflows/actor2/runtime.rs)

   • Complex FDB transaction logic with multiple memory calculations could benefit from better error handling for edge cases
   • Large transaction bodies (500+ lines) might hit FDB transaction limits under high contention

3. Resource Allocation Logic

   • Bin-packing algorithm in allocate_actor could lead to memory fragmentation over time
   • No apparent cleanup for stale allocation records

🔒 Security Considerations

1. Unsafe Code (packages/common/util/id/src/lib.rs:204)

   let s = unsafe { String::from_utf8_unchecked(buf.to_vec()) };

   While documented as safe (ASCII), consider using safe conversion for defense in depth.

2. Environment Variable Handling

   • Container runner accepts ROOT_USER_ENABLED and VECTOR_SOCKET_ADDR - ensure these are properly validated in production environments

⚡ Performance Considerations

1. Efficient Improvements

   • New ID system with V1 format (30-char base36) is more efficient than UUIDs for certain use cases
   • FDB snapshot reads reduce transaction conflicts in allocation logic

2. Areas for Optimization

   • ClickHouse actor_runners table could benefit from better partitioning strategy
   • Vector message serialization in log_shipper happens per message - consider batching

🧪 Test Coverage

1. Positive Changes

   • TypeScript test includes both HTTP and UDP protocol testing
   • Test covers actor lifecycle (create → ready → destroy)

2. Missing Coverage

   • No integration tests for new actor allocation algorithm
   • FDB transaction rollback scenarios not covered
   • Error handling paths in log shipping not tested

📋 Code Quality

Good Practices:

• Comprehensive error handling with proper context
• Well-structured workflow pattern with state management
• Clear separation of concerns (allocation, runtime, destruction)

Areas for Improvement:

• Some functions are quite large (e.g., allocate_actor at 200+ lines)
• Magic numbers could be better documented (e.g., ACTOR_START_THRESHOLD_MS)
• Missing documentation for complex allocation algorithm

🐳 Docker & Configuration

• Docker builds correctly include all new binaries
• Configuration changes are minimal and focused
• Multi-stage build properly optimized

---

Recommendations

1. Fix the critical build error in container-runner/main.rs
2. Address the tokio async block issue as suggested by graphite-app
3. Add database migration rollback for the runner_id column
4. Consider adding integration tests for the new allocation logic
5. Document the allocation algorithm for future maintainers

The overall approach is sound and the implementation follows good patterns. Once the critical issues are addressed, this should be ready for merge.

---

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
rivet-site	Error			Aug 21, 2025 8:20pm

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: Fix new actors working on docker compose

Reviewing this PR for code quality, potential bugs, performance, security, and test coverage.

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze core Rust changes in packages/edge/
• Review database migrations
• Check Docker and configuration changes
• Examine test modifications
• Provide comprehensive feedback on code quality
• Identify potential bugs and issues
• Assess performance considerations
• Review security implications
• Evaluate test coverage

---

Review Summary

This PR implements significant changes to support "new actors" with enhanced ID management and Docker Compose compatibility. Overall the changes are well-structured, but there are several issues that need attention.

🐛 Critical Issues

1. Build Error in container-runner (packages/edge/infra/client/container-runner/src/main.rs:65)

   let exit_code = match container::run(
       msg_tx.clone(),
       &actor_path,  // ❌ `actor_path` is undefined
       &container_id,
       root_user_enabled,
   )

   Should likely be runner_path instead of actor_path.

2. Tokio async block issue (Already identified by graphite-app at packages/edge/infra/client/manager/src/main.rs:193)

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into)? },  // ❌ Incorrect ? usage

   Should be:

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into) },

⚠️ Potential Issues

1. Database Migration Concerns

   • add_runner_id.up.sql adds a column but no down migration provided for reversibility
   • No indices defined for the new runner_id column which could impact query performance

2. Memory Management in Runtime (packages/edge/services/pegboard/src/workflows/actor2/runtime.rs)

   • Complex FDB transaction logic with multiple memory calculations could benefit from better error handling for edge cases
   • Large transaction bodies (500+ lines) might hit FDB transaction limits under high contention

3. Resource Allocation Logic

   • Bin-packing algorithm in allocate_actor could lead to memory fragmentation over time
   • No apparent cleanup for stale allocation records

🔒 Security Considerations

1. Unsafe Code (packages/common/util/id/src/lib.rs:204)

   let s = unsafe { String::from_utf8_unchecked(buf.to_vec()) };

   While documented as safe (ASCII), consider using safe conversion for defense in depth.

2. Environment Variable Handling

   • Container runner accepts ROOT_USER_ENABLED and VECTOR_SOCKET_ADDR - ensure these are properly validated in production environments

⚡ Performance Considerations

1. Efficient Improvements

   • New ID system with V1 format (30-char base36) is more efficient than UUIDs for certain use cases
   • FDB snapshot reads reduce transaction conflicts in allocation logic

2. Areas for Optimization

   • ClickHouse actor_runners table could benefit from better partitioning strategy
   • Vector message serialization in log_shipper happens per message - consider batching

🧪 Test Coverage

1. Positive Changes

   • TypeScript test includes both HTTP and UDP protocol testing
   • Test covers actor lifecycle (create → ready → destroy)

2. Missing Coverage

   • No integration tests for new actor allocation algorithm
   • FDB transaction rollback scenarios not covered
   • Error handling paths in log shipping not tested

📋 Code Quality

Good Practices:

• Comprehensive error handling with proper context
• Well-structured workflow pattern with state management
• Clear separation of concerns (allocation, runtime, destruction)

Areas for Improvement:

• Some functions are quite large (e.g., allocate_actor at 200+ lines)
• Magic numbers could be better documented (e.g., ACTOR_START_THRESHOLD_MS)
• Missing documentation for complex allocation algorithm

🐳 Docker & Configuration

• Docker builds correctly include all new binaries
• Configuration changes are minimal and focused
• Multi-stage build properly optimized

---

Recommendations

1. Fix the critical build error in container-runner/main.rs
2. Address the tokio async block issue as suggested by graphite-app
3. Add database migration rollback for the runner_id column
4. Consider adding integration tests for the new allocation logic
5. Document the allocation algorithm for future maintainers

The overall approach is sound and the implementation follows good patterns. Once the critical issues are addressed, this should be ready for merge.

---

[claude]

Claude finished @MasterPtato's task —— View job

---

PR Review: Fix new actors working on docker compose

Reviewing this PR for code quality, potential bugs, performance, security, and test coverage.

Todo List:

• Read repository guidelines (CLAUDE.md)
• Analyze core Rust changes in packages/edge/
• Review database migrations
• Check Docker and configuration changes
• Examine test modifications
• Provide comprehensive feedback on code quality
• Identify potential bugs and issues
• Assess performance considerations
• Review security implications
• Evaluate test coverage

---

Review Summary

This PR implements significant changes to support "new actors" with enhanced ID management and Docker Compose compatibility. Overall the changes are well-structured, but there are several issues that need attention.

🐛 Critical Issues

1. Build Error in container-runner (packages/edge/infra/client/container-runner/src/main.rs:65)

   let exit_code = match container::run(
       msg_tx.clone(),
       &actor_path,  // ❌ `actor_path` is undefined
       &container_id,
       root_user_enabled,
   )

   Should likely be runner_path instead of actor_path.

2. Tokio async block issue (Already identified by graphite-app at packages/edge/infra/client/manager/src/main.rs:193)

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into)? },  // ❌ Incorrect ? usage

   Should be:

   async { metrics_task.await.map_err(Into::<anyhow::Error>::into) },

⚠️ Potential Issues

1. Database Migration Concerns

   • add_runner_id.up.sql adds a column but no down migration provided for reversibility
   • No indices defined for the new runner_id column which could impact query performance

2. Memory Management in Runtime (packages/edge/services/pegboard/src/workflows/actor2/runtime.rs)

   • Complex FDB transaction logic with multiple memory calculations could benefit from better error handling for edge cases
   • Large transaction bodies (500+ lines) might hit FDB transaction limits under high contention

3. Resource Allocation Logic

   • Bin-packing algorithm in allocate_actor could lead to memory fragmentation over time
   • No apparent cleanup for stale allocation records

🔒 Security Considerations

1. Unsafe Code (packages/common/util/id/src/lib.rs:204)

   let s = unsafe { String::from_utf8_unchecked(buf.to_vec()) };

   While documented as safe (ASCII), consider using safe conversion for defense in depth.

2. Environment Variable Handling

   • Container runner accepts ROOT_USER_ENABLED and VECTOR_SOCKET_ADDR - ensure these are properly validated in production environments

⚡ Performance Considerations

1. Efficient Improvements

   • New ID system with V1 format (30-char base36) is more efficient than UUIDs for certain use cases
   • FDB snapshot reads reduce transaction conflicts in allocation logic

2. Areas for Optimization

   • ClickHouse actor_runners table could benefit from better partitioning strategy
   • Vector message serialization in log_shipper happens per message - consider batching

🧪 Test Coverage

1. Positive Changes

   • TypeScript test includes both HTTP and UDP protocol testing
   • Test covers actor lifecycle (create → ready → destroy)

2. Missing Coverage

   • No integration tests for new actor allocation algorithm
   • FDB transaction rollback scenarios not covered
   • Error handling paths in log shipping not tested

📋 Code Quality

Good Practices:

• Comprehensive error handling with proper context
• Well-structured workflow pattern with state management
• Clear separation of concerns (allocation, runtime, destruction)

Areas for Improvement:

• Some functions are quite large (e.g., allocate_actor at 200+ lines)
• Magic numbers could be better documented (e.g., ACTOR_START_THRESHOLD_MS)
• Missing documentation for complex allocation algorithm

🐳 Docker & Configuration

• Docker builds correctly include all new binaries
• Configuration changes are minimal and focused
• Multi-stage build properly optimized

---

Recommendations

1. Fix the critical build error in container-runner/main.rs
2. Address the tokio async block issue as suggested by graphite-app
3. Add database migration rollback for the runner_id column
4. Consider adding integration tests for the new allocation logic
5. Document the allocation algorithm for future maintainers

The overall approach is sound and the implementation follows good patterns. Once the critical issues are addressed, this should be ready for merge.

---

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.

[claude]

Claude encountered an error —— View job

---

I'll analyze this and get back to you.