fix(gas): optimize loops

[MasterPtato]

No description provided.

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
rivetkit-serverless	Ready	Preview	Comment	Dec 2, 2025 7:11pm

3 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
rivet-cloud	Ignored			Dec 2, 2025 7:11pm
rivet-inspector	Ignored	Preview		Dec 2, 2025 7:11pm
rivet-site	Ignored	Preview		Dec 2, 2025 7:11pm

[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

• feat(pegboard): move pegboard serverless to wf #3416 : 2 dependent PRs (#3450 , #3571 )
• fix(runtime): evict runners on SIGTERM, add periodic shutdown progress messages #3550
• fix(pb): implement events and commands for actor wfs #3543
• fix: make all uses of protocol handle v4 <-> v3 #3528
• fix(pb): simplify runner wf #3483
• fix(gas): fix loop forgotten bug due to concurrency #3482
• fix(pb): rewrite runner wf to handle batch signals #3480
• fix(gas): fix batch listen, fix history for graceful signal send in workflows #3479
• feat(gas): add batch listen #3478
• chore(gas): add test for history with holes #3477
• chore: change streamingmode to exact for ranges with limits #3476
• fix(gas): optimize loops #3475 👈 (View in Graphite)
• fix: parallelize publish signal awaits #3523
• chore: fix diff between ee, fix plural api query params #3524
• 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.

[claude]

PR Review: fix(gas): optimize loops

Summary

This PR optimizes loop performance in the workflow engine by:

1. Parallelizing database operations using tokio::join!
2. Reducing database write frequency from every iteration to every 20 iterations (controlled by LOOP_ITERS_PER_COMMIT)

Code Quality & Best Practices

Strengths:

• ✅ The optimization approach is sound - parallelizing independent DB operations will reduce latency
• ✅ Good use of tokio::join! to run loop event commit, branch commit, and user code concurrently
• ✅ Helpful inline comments explaining the optimization strategy (lines 949-955)
• ✅ Maintains backward compatibility with existing loop behavior

Concerns:

1. Missing Safety Documentation ⚠️
   The comment on line 45 mentions "mark previous loop history to forgotten" but this only happens when upsert_workflow_loop_event is called. With the new batching, history is only marked as forgotten every 20 iterations instead of every iteration. This could have implications:

   • The "active" history will accumulate 20 iterations worth of events before being moved to "forgotten" history
   • Consider documenting this behavior change and whether it impacts recovery scenarios

2. Hard-coded Magic Number ⚠️

   const LOOP_ITERS_PER_COMMIT: usize = 20;

   While defined as a constant, there's no justification for why 20 was chosen. Consider:

   • Adding a comment explaining the rationale (performance vs. recovery granularity tradeoff)
   • Whether this should be configurable based on use case (tight loops with small state vs. expensive operations)

3. State Loss Risk 🔴 CRITICAL
   If a workflow crashes between iterations (e.g., at iteration 15), the state from iterations 1-14 will be lost since they were never persisted. The workflow will restart from iteration 0 when replayed.

   Example scenario:

   • Loop runs iterations 1-15
   • Workflow crashes at iteration 15
   • State was only committed at iteration 0
   • On replay, workflow restarts from iteration 0, redoing all 15 iterations

   This breaks the workflow engine's durability guarantees. The current behavior ensures every iteration is recoverable.

Potential Bugs

Critical Issue: The optimization introduces a correctness bug. Looking at line 994:

if iteration % LOOP_ITERS_PER_COMMIT == 0 {
    self.db.upsert_workflow_loop_event(...)
}

The modulo check means:

• Iteration 0: NOT committed (0 % 20 = 0, but handled separately in initial creation)
• Iteration 1-19: NOT committed
• Iteration 20: committed (20 % 20 = 0)
• Iteration 21-39: NOT committed
• etc.

But the loop event was already created at iteration 0 (lines 892-904), so iteration 20 would be the first update. However, if the loop breaks at iteration 15, the final state IS committed (lines 1021-1032), so that case is handled.

The real issue: If a workflow crashes/restarts between commits (e.g., at iteration 15), it will replay from iteration 0, not iteration 15. This changes the recovery semantics.

Performance Considerations

Positive:

• Reducing DB writes from N to N/20 for a loop with N iterations will significantly improve throughput
• Parallelizing the initial loop event commit with the first iteration's branch commit is clever

Concerns:

• The tradeoff is between performance and crash recovery granularity
• For long-running loops (thousands of iterations), losing progress on crash could be expensive
• Consider profiling with realistic workloads to validate the 20-iteration interval

Security Concerns

No security issues identified. The changes are confined to internal workflow state management.

Test Coverage

Missing tests for the optimization:

1. No test verifies that state commits happen every 20 iterations
2. No test validates crash/restart behavior with the new batching
3. No test for the parallelization of DB operations

Recommended tests:

// Test that loop state is persisted every LOOP_ITERS_PER_COMMIT iterations
#[test]
async fn test_loop_commit_batching() {
    // Run a loop for 50 iterations
    // Kill and restart the workflow at iteration 35
    // Verify it resumes from iteration 20 (last commit), not iteration 0
}

// Test that final state is always committed on Loop::Break
#[test]
async fn test_loop_final_state_commit() {
    // Run loop that breaks at arbitrary iteration (e.g., 15)
    // Verify final state is persisted correctly
}

Recommendations

1. Consider reverting or adding a feature flag - The durability implications need careful evaluation
2. Document the tradeoff - Add detailed comments explaining why batching is safe (or make it configurable)
3. Add comprehensive tests - Especially for crash/recovery scenarios
4. Profile before merging - Measure actual performance impact with realistic loop workloads

Questions for Author

1. Have you tested crash/restart behavior with loops that run for 10-50 iterations?
2. What happens to workflows in-flight when this change is deployed? Will they replay from iteration 0?
3. Was 20 iterations chosen based on profiling data or intuition?
4. Are there use cases where loops hold critical state that must be persisted every iteration?

---

Overall Assessment: The optimization is well-intentioned but potentially introduces a subtle correctness issue around crash recovery. I'd recommend either:

• Making this configurable with a default that preserves current behavior
• OR thoroughly documenting the new recovery semantics and adding tests to validate them

Happy to discuss further! 🤖

Generated with Claude Code

[claude]

PR Review: fix(gas): optimize loops

Summary

This PR optimizes loop performance in the workflow engine by:

1. Parallelizing database operations using tokio::join!
2. Reducing database write frequency from every iteration to every 20 iterations (controlled by LOOP_ITERS_PER_COMMIT)

Code Quality & Best Practices

Strengths:

• ✅ The optimization approach is sound - parallelizing independent DB operations will reduce latency
• ✅ Good use of tokio::join! to run loop event commit, branch commit, and user code concurrently
• ✅ Helpful inline comments explaining the optimization strategy (lines 949-955)
• ✅ Maintains backward compatibility with existing loop behavior

Concerns:

1. Missing Safety Documentation ⚠️
   The comment on line 45 mentions "mark previous loop history to forgotten" but this only happens when upsert_workflow_loop_event is called. With the new batching, history is only marked as forgotten every 20 iterations instead of every iteration. This could have implications:

   • The "active" history will accumulate 20 iterations worth of events before being moved to "forgotten" history
   • Consider documenting this behavior change and whether it impacts recovery scenarios

2. Hard-coded Magic Number ⚠️

   const LOOP_ITERS_PER_COMMIT: usize = 20;

   While defined as a constant, there's no justification for why 20 was chosen. Consider:

   • Adding a comment explaining the rationale (performance vs. recovery granularity tradeoff)
   • Whether this should be configurable based on use case (tight loops with small state vs. expensive operations)

3. State Loss Risk 🔴 CRITICAL
   If a workflow crashes between iterations (e.g., at iteration 15), the state from iterations 1-14 will be lost since they were never persisted. The workflow will restart from iteration 0 when replayed.

   Example scenario:

   • Loop runs iterations 1-15
   • Workflow crashes at iteration 15
   • State was only committed at iteration 0
   • On replay, workflow restarts from iteration 0, redoing all 15 iterations

   This breaks the workflow engine's durability guarantees. The current behavior ensures every iteration is recoverable.

Potential Bugs

Critical Issue: The optimization introduces a correctness bug. Looking at line 994:

if iteration % LOOP_ITERS_PER_COMMIT == 0 {
    self.db.upsert_workflow_loop_event(...)
}

The modulo check means:

• Iteration 0: NOT committed (0 % 20 = 0, but handled separately in initial creation)
• Iteration 1-19: NOT committed
• Iteration 20: committed (20 % 20 = 0)
• Iteration 21-39: NOT committed
• etc.

But the loop event was already created at iteration 0 (lines 892-904), so iteration 20 would be the first update. However, if the loop breaks at iteration 15, the final state IS committed (lines 1021-1032), so that case is handled.

The real issue: If a workflow crashes/restarts between commits (e.g., at iteration 15), it will replay from iteration 0, not iteration 15. This changes the recovery semantics.

Performance Considerations

Positive:

• Reducing DB writes from N to N/20 for a loop with N iterations will significantly improve throughput
• Parallelizing the initial loop event commit with the first iteration's branch commit is clever

Concerns:

• The tradeoff is between performance and crash recovery granularity
• For long-running loops (thousands of iterations), losing progress on crash could be expensive
• Consider profiling with realistic workloads to validate the 20-iteration interval

Security Concerns

No security issues identified. The changes are confined to internal workflow state management.

Test Coverage

Missing tests for the optimization:

1. No test verifies that state commits happen every 20 iterations
2. No test validates crash/restart behavior with the new batching
3. No test for the parallelization of DB operations

Recommended tests:

// Test that loop state is persisted every LOOP_ITERS_PER_COMMIT iterations
#[test]
async fn test_loop_commit_batching() {
    // Run a loop for 50 iterations
    // Kill and restart the workflow at iteration 35
    // Verify it resumes from iteration 20 (last commit), not iteration 0
}

// Test that final state is always committed on Loop::Break
#[test]
async fn test_loop_final_state_commit() {
    // Run loop that breaks at arbitrary iteration (e.g., 15)
    // Verify final state is persisted correctly
}

Recommendations

1. Consider reverting or adding a feature flag - The durability implications need careful evaluation
2. Document the tradeoff - Add detailed comments explaining why batching is safe (or make it configurable)
3. Add comprehensive tests - Especially for crash/recovery scenarios
4. Profile before merging - Measure actual performance impact with realistic loop workloads

Questions for Author

1. Have you tested crash/restart behavior with loops that run for 10-50 iterations?
2. What happens to workflows in-flight when this change is deployed? Will they replay from iteration 0?
3. Was 20 iterations chosen based on profiling data or intuition?
4. Are there use cases where loops hold critical state that must be persisted every iteration?

---

Overall Assessment: The optimization is well-intentioned but potentially introduces a subtle correctness issue around crash recovery. I'd recommend either:

• Making this configurable with a default that preserves current behavior
• OR thoroughly documenting the new recovery semantics and adding tests to validate them

Happy to discuss further! 🤖

Review generated with Claude Code

[claude]

Code Review: Loop Optimization

Summary

This PR optimizes loop performance in the workflow engine by reducing database write frequency and parallelizing database operations. The changes demonstrate good performance-conscious engineering.

---

✅ Strengths

1. Smart Database Batching: Introducing LOOP_ITERS_PER_COMMIT (20 iterations) to reduce database writes is a solid optimization that will significantly improve throughput for tight loops.

2. Effective Parallelization: Using tokio::join! to run three operations concurrently (lines 956-979) is excellent:

   • Loop event commit (first iteration only)
   • Branch event commit (if needed)
   • User's loop code execution

   This eliminates sequential database round-trips that were blocking the critical path.

3. Code Documentation: The detailed comment explaining the optimization logic (lines 949-955) is very helpful for future maintainers.

4. Correct Async Future Handling: The deferred future pattern (lines 892-904) properly clones necessary data and avoids lifetime issues.

---

🔍 Potential Issues

1. Data Loss Risk on Crashes (Medium Priority)

With batched commits every 20 iterations, if a workflow crashes between commits, you could lose up to 19 iterations of state updates.

Questions:

• Is this acceptable given the workflow replay mechanism?
• Should LOOP_ITERS_PER_COMMIT be configurable per workflow or documented as a tradeoff?
• Does the event history replay correctly handle this scenario?

2. Missing Final Commit on Continue (Critical - Potential Bug)

At line 994-1007, loop state is only committed if iteration % LOOP_ITERS_PER_COMMIT == 0. However, if the loop breaks at an iteration that's not a multiple of 20, the last N iterations won't be committed.

Example:

// Loop runs for 25 iterations
// Commits happen at iteration 20
// Iterations 21-25 state changes are lost
// Only the final Break state is committed (lines 1021-1032)

Recommendation: Consider also committing when iteration > 0 && iteration % LOOP_ITERS_PER_COMMIT != 0 before the loop check to ensure intermediate state isn't lost on errors between iteration 21-39, etc.

Actually, looking more carefully: the Loop::Break case always commits (lines 1021-1032), so the final state is preserved. However, if the workflow crashes/errors during iteration 25 (not at the Break), iterations 21-25 state could be lost. This depends on error handling semantics.

3. Race Condition in Future Take (Low Priority)

Line 958: loop_event_commit_fut.take() - this is safe because it only runs on iteration 0, but the mutable borrow pattern could be confusing. Consider a comment explaining why .take() is used here.

4. Clone Overhead (Minor)

Lines 884-889 clone several fields to move into the future. For hot loops, consider if these clones have measurable overhead:

• loop_location.clone()
• name.clone()
• loop_location().cloned()

Probably negligible, but worth profiling if this is a very hot path.

---

🎯 Code Quality

Style Adherence: ✅

• Follows existing patterns in the codebase
• Structured logging maintained (lines 949-955 comment)
• Consistent with error handling patterns

Best Practices: ✅

• No glob imports from anyhow
• Proper use of tokio::join! for parallelization
• Good separation of concerns

---

🧪 Testing Recommendations

1. Add tests for batch commit boundary conditions:

   • Loop that runs exactly LOOP_ITERS_PER_COMMIT iterations
   • Loop that runs LOOP_ITERS_PER_COMMIT + 1 iterations
   • Loop that errors at iteration LOOP_ITERS_PER_COMMIT + 5

2. Replay testing:

   • Verify workflow replay works correctly when state was committed at iteration N but crash happened at iteration N+10

3. Performance benchmarks:

   • Measure improvement for tight loops (1000+ iterations)
   • Verify parallel execution actually improves performance vs sequential

---

🔒 Security

No security concerns identified. The optimization is purely performance-related and doesn't change access control or data validation.

---

📊 Performance Expectations

Expected improvements:

• ~95% reduction in database writes for long loops (1 write per 20 iterations vs every iteration)
• Reduced latency from parallel DB operations (potentially 2x faster per iteration)
• Better throughput for workflow-heavy workloads

Potential regressions:

• Slightly higher memory usage for deferred futures
• Potential data loss on crashes (see issue [SVC-2555] Set up issue templates #1 above)

---

✏️ Minor Suggestions

1. Line 889: Consider adding a comment explaining why nested_loop_location is cloned here
2. Line 994: Add a comment explaining the batching strategy
3. Consider extracting the constant into a config if different workflows have different performance characteristics

---

Verdict: ✅ Approve with Minor Concerns

This is a well-executed optimization that should significantly improve loop performance. The main concern is ensuring the batched commit strategy doesn't cause data loss in edge cases. I recommend:

1. Verifying that the replay mechanism handles missing intermediate state correctly
2. Adding tests for the boundary conditions mentioned above
3. Documenting the tradeoff in comments or documentation

Great work on the optimization! 🚀

[claude]

Pull Request Review: Loop Optimization

Summary

This PR optimizes the loop execution in the Gasoline workflow engine by reducing database writes and parallelizing database transactions. The changes introduce batched state commits and parallel execution of DB operations.

---

✅ Strengths

1. Performance Optimization: The core optimization is sound - reducing DB writes from every iteration to every 20 iterations (controlled by LOOP_ITERS_PER_COMMIT) will significantly improve performance for long-running loops.

2. Parallelization: Using tokio::join\! to run the loop event commit, branch event commit, and user code simultaneously is a clever optimization that reduces sequential DB latency.

3. Clear Documentation: The inline comment at lines 949-955 clearly explains the optimization strategy, which is helpful given the complexity introduced.

4. Correct Final State Handling: The code correctly ensures that the final state is always written when Loop::Break is called (lines 1020-1032), regardless of the iteration count.

---

⚠️ Issues & Concerns

1. Critical: Potential State Loss on Failure (High Priority)

Location: Lines 986-1007

If a workflow crashes or is interrupted between iterations that are NOT multiples of 20, the loop state will be lost. When the workflow replays:

• It will restart from the last committed iteration (e.g., iteration 20)
• But the actual execution may have progressed to iteration 35
• The state mutations from iterations 21-35 will be lost

Example Scenario:

// Loop that increments state
ctx.loope(0, |ctx, counter| {
    *counter += 1;
    // Imagine workflow crashes at iteration 35
    // On replay, counter restarts from 20 (last commit)
    // 15 iterations of work are lost
    Ok(Loop::Continue)
}).await?;

Impact: This breaks the durability guarantee that workflows typically provide. The workflow engine should be able to replay from any point without losing state.

Recommendation:

• Consider whether this trade-off is acceptable for your use case
• Add documentation warning users that loop state may be rolled back on failure
• OR: Keep iteration count accurate but batch only the state payload
• OR: Provide a configuration option for users to control this behavior

2. Code Clarity: Complex Control Flow (Medium Priority)

Location: Lines 956-979

The tokio::join\! with the Option future for loop_event_commit_fut is difficult to follow. The first future does different things on the first iteration vs subsequent iterations.

Recommendation: Consider extracting this into a helper function or adding more inline comments explaining the state machine:

// Iteration 0: Commits initial loop event
// Iteration 1-19: No-op  
// Iteration 20+: Only commits on multiples of LOOP_ITERS_PER_COMMIT

3. Potential Bug: Iteration Count Off-by-One? (Medium Priority)

Location: Lines 994, 1001

The check iteration % LOOP_ITERS_PER_COMMIT == 0 happens AFTER incrementing iteration (line 988). This means:

• Iteration 0: Not committed here (committed via loop_event_commit_fut)
• Iteration 20: Committed ✓
• Iteration 40: Committed ✓

But what about the state mutation that happens in iteration 1? The state is modified (line 988: iteration += 1) but if the loop continues from 1 to 19, no intermediate state is persisted.

Question: Is this intentional? Should the comment on line 45 be updated to clarify this behavior?

4. Missing Test Coverage (Medium Priority)

Location: PR does not include test changes

Given the complexity of this optimization and the potential for state loss, this change needs comprehensive test coverage:

1. Long loop test: Verify loops with >100 iterations work correctly
2. Crash/replay test: Simulate a crash at iteration 25 and verify correct replay behavior
3. Modulo boundary test: Test loops that end exactly at iteration 20, 40, etc.
4. State persistence test: Verify that state mutations are correctly persisted every 20 iterations

Recommendation: Add tests to engine/packages/gasoline/tests/workflows/loop_test.rs

---

🔍 Minor Issues

5. Magic Number (Low Priority)

Location: Line 46

The constant LOOP_ITERS_PER_COMMIT = 20 seems reasonable but lacks justification.

Recommendation: Add a comment explaining why 20 was chosen (e.g., "Balances DB load with replay overhead" or link to benchmarking data).

6. Inconsistent Error Propagation (Low Priority)

Location: Lines 981-982

The pattern of propagating results:

loop_event_commit_res?;
branch_commit_res?;

Could be simplified with try_join\! instead of join\! if all operations can fail. However, the current approach may be intentional to ensure user code runs even if DB commits fail.

Question: Is there a reason to run the user's loop code even if the DB commits fail? If not, consider tokio::try_join\!.

---

🛡️ Security & Performance

• No security concerns identified ✓
• Performance improvement: Excellent - reduces DB writes by ~95% for long loops ✓
• Latency improvement: Parallelizing DB operations reduces critical path latency ✓

---

📋 Recommendations

1. High Priority: Document the state loss behavior and consider whether it's acceptable
2. High Priority: Add comprehensive test coverage for the optimized loop behavior
3. Medium Priority: Clarify the iteration counting logic and update comments
4. Low Priority: Consider making LOOP_ITERS_PER_COMMIT configurable per-workflow

---

✅ Conclusion

This is a well-intentioned performance optimization with clear benefits for long-running loops. However, the trade-off between performance and durability guarantees needs careful consideration. The primary concern is potential state loss on workflow failure/replay, which may or may not be acceptable depending on Rivet's workflow semantics.

Recommendation:

• If state loss is acceptable: Merge after adding tests and documentation
• If state loss is NOT acceptable: Revise the approach to maintain full durability

Would you like me to elaborate on any of these points or help write tests for this functionality?

[claude]

PR Review: fix(gas): optimize loops

Summary

This PR optimizes the workflow loop implementation by:

1. Parallelizing database operations with user code execution using tokio::join!
2. Reducing database commits from every iteration to every 20 iterations (configurable via LOOP_ITERS_PER_COMMIT)
3. Deferring initial loop event commit to run concurrently with first iteration

Code Quality: ✅ Excellent

Strengths:

• Clear optimization strategy with excellent inline documentation (lines 949-955)
• Well-structured use of tokio::join! for parallelization
• Good separation of concerns between loop event and branch event commits
• Maintains backward compatibility by still replaying from saved state

Style compliance:

• ✅ Follows hard tab formatting
• ✅ Proper use of anyhow::Result
• ✅ Good tracing instrumentation already in place
• ✅ Follows existing code patterns

Potential Issues

1. ⚠️ State Loss Risk on Crashes (Medium Severity)

Location: workflow.rs:994-1007

With commits only happening every 20 iterations, a workflow crash between commits could lose up to 19 iterations of progress. On replay, the loop would restart from the last committed iteration.

Impact:

• Loops with expensive operations (API calls, heavy computation) per iteration would redo significant work
• Acceptable for lightweight loops but problematic for heavy ones

Recommendation:
Consider making LOOP_ITERS_PER_COMMIT configurable per-loop or documenting this trade-off in the function's doc comment.

2. ⚠️ Missing Error Context (Low Severity)

Location: workflow.rs:981-982

Errors from parallel operations lose context about which operation failed. Consider adding .context() calls.

3. 🔍 Subtle Async Pattern (Low Severity)

Location: workflow.rs:958-959

Using .take() on loop_event_commit_fut inside the tokio::join! works correctly, but the mutable borrow across the async boundary is subtle. This would benefit from a comment explaining why take() is safe here.

4. 📊 Metrics Impact (Informational)

Location: workflow.rs:1045-1048

The LOOP_ITERATION_DURATION metric remains unaffected, which is good. However, consider adding metrics for:

• Number of iterations between commits
• Loop replay recovery time (when resuming from saved state)

Performance: ✅ Excellent

The optimizations are well-designed:

1. Parallelization benefit: DB commits now run concurrently with user code instead of blocking
2. Reduced I/O: 20x reduction in database writes for long-running loops
3. Smart batching: Still commits immediately on Loop::Break to avoid data loss

Estimated impact: For a 1000-iteration loop with 50ms user code per iteration:

• Before: ~1000 DB commits (assuming ~10ms each) = +10 seconds
• After: ~50 DB commits = +0.5 seconds
• Savings: ~9.5 seconds (19% faster for this workload)

Security: ✅ No concerns

• No new external inputs or attack vectors
• Database operations maintain same authorization checks
• No SQL injection or XSS risks (using parameterized queries)

Test Coverage: ⚠️ Needs attention

Missing test scenarios:

1. Loop crash recovery with uncommitted iterations
2. Very long loops (>100 iterations) to verify commit batching
3. Parallel execution correctness (loop event + branch event + user code)
4. Nested loops still work correctly with batched commits

Recommendations Summary

Must address:

• Add test coverage for crash recovery scenarios
• Document the commit batching behavior and trade-offs in function docs

Should address:

• Add error context to parallel operation results
• Consider making commit interval configurable for heavy loops
• Add comment explaining loop_event_commit_fut.take() safety

Nice to have:

• Add metrics for replay recovery and commit intervals
• Consider adding tracing for skipped commits (debugging aid)

Overall Assessment: ✅ Approve with suggestions

This is a well-thought-out optimization that significantly improves loop performance. The code quality is high and follows project conventions. The main concern is the potential for work loss on crashes, which should be documented and tested. The optimization is sound and provides real performance benefits for workflow-heavy workloads.

Recommendation: Approve after addressing test coverage and documentation suggestions.

[graphite-app]

Merge activity

• Dec 3, 12:33 AM UTC: NathanFlurry added this pull request to the Graphite merge queue.
• Dec 3, 12:33 AM UTC: CI is running for this pull request on a draft pull request (#3577) due to your merge queue CI optimization settings.
• Dec 3, 12:34 AM UTC: Merged by the Graphite merge queue via draft PR: #3577.