feat: v0.7.0 — Task & Pipeline Loops

[dean0x]

Summary

Adds iterative task and pipeline loop execution to Backbeat (v0.7.0). Loops run a task or pipeline repeatedly, evaluating an exit condition after each iteration to decide whether to continue, keep, or discard results.

• Retry strategy: Re-run until exit condition passes or limits reached
• Optimize strategy: Track best score across iterations (maximize/minimize)
• Pipeline loops: Run multi-step pipelines per iteration with linear dependency chains
• Recovery: Self-healing on startup — rebuilds in-memory maps, recovers stuck iterations
• Cleanup: cleanupOldLoops in RecoveryManager (7-day retention, FK cascade deletes iterations)

Key design decisions

• Loop iteration chaining uses prompt enrichment from checkpoints (no dependsOn to avoid pre-resolved dep deadlock)
• Only the tail task of a pipeline triggers exit condition evaluation (R4)
• Atomic iteration start via runInTransaction prevents double-start (R4)
• Timestamps use epoch number (aligned with Task/Schedule/Worker convention)
• LoopIteration.taskId is optional to handle ON DELETE SET NULL safely

What's included

• Domain: Loop, LoopIteration types, LoopStatus/LoopStrategy enums, factory functions
• Events: LoopCreated, LoopCompleted, LoopCancelled, LoopIterationCompleted
• Repository: SQLiteLoopRepository with prepared statements, sync ops for transactions, cleanup
• Handler: LoopHandler — 1,100-line event-driven iteration engine with recordAndContinue helper
• Service: LoopManagerService for create/cancel/list/get operations
• MCP tools: CreateLoop, LoopStatus, ListLoops, CancelLoop
• CLI: beat loop create|status|list|cancel commands
• Migration v10: loops + loop_iterations tables with indexes and FK cascade
• Tests: 104 new tests (52 repo, 24 manager, 20 handler, 5 integration, 3 recovery)
• Tech debt fixes: Timestamp alignment, optional taskId, extracted helper, removed dead param, loop cleanup

Stats

• 22 commits, 32 files changed, +5,910 / −82 lines
• 1,102 total tests passing (was 998 on main)
• Snyk SAST: 0 issues, Biome: clean

Test plan

• npm run build — clean compile
• npm run test:core — domain type tests
• npm run test:repositories — loop repo CRUD, cleanup, NULL taskId, cascade
• npm run test:services — loop manager + recovery manager cleanup tests
• npm run test:handlers — loop handler lifecycle, optimize, pipeline, recovery
• npm run test:integration — end-to-end retry loop, optimize loop, cancel
• npm run test:cli — CLI routing
• npm run test:adapters — MCP tool registration
• Manual: beat loop create --strategy retry --exit-condition 'true' --prompt 'test'

[greptile-apps]

Confidence Score: 4/5

• PR is on the happy path to merge — no new blocking issues found; all prior critical concerns have been addressed.
• All P0/P1 concerns from the prior round (blocking eval, FK ordering, non-atomic writes, null taskId, pipeline intermediate failure, unguarded transaction failures) have been resolved. The code now uses async exit condition evaluation, wraps critical DB writes in transactions with proper error fallbacks, and correctly guards null taskIds. 104 new tests including integration coverage further reduce merge risk. Docking one point from 5 given the overall size and complexity of the change (1,263-line handler, 22 commits) and the value of a final smoke-test pass against the test plan before merging.
• src/services/handlers/loop-handler.ts warrants a final read-through alongside the integration tests given its size and centrality to the feature.

Important Files Changed

Filename	Overview
src/services/handlers/loop-handler.ts	1,263-line event-driven iteration engine. Prior concerns (blocking execSync, FK ordering, non-atomic TaskFailed writes, unguarded null taskId, pipeline intermediate failure) have all been resolved — async eval is now delegated to ShellExitConditionEvaluator, task save precedes iteration record in a transaction, and handlePipelineIntermediateTask correctly handles intermediate failures. Recovery paths, timer cleanup, and in-memory map maintenance look correct.
src/services/exit-condition-evaluator.ts	Async exit condition evaluator using promisified exec. Clean DI boundary for testability; handles retry (exit code 0 = pass) and optimize (last stdout line parsed as float) strategies correctly. Timeout, NaN/Infinity, and exec-error paths are all handled.
src/implementations/loop-repository.ts	SQLite repository with prepared statements, Zod boundary validation, and sync counterparts for transactional use. Row-to-domain and domain-to-row conversions are well-structured. cleanupOldLoops uses CASCADE for iteration cleanup.
src/services/loop-manager.ts	Service layer with thorough input validation. The previously flagged undefined taskId guard is now present (lines 272-279), safely skipping cancellation for itérations with cleaned-up tasks. cancelLoop correctly cancels running tasks before emitting LoopCancelled.
src/implementations/database.ts	Migration v10 adds loops and loop_iterations tables with FK cascade, CHECK constraints, and appropriate indexes. runInTransaction correctly preserves BackbeatError types.
src/services/recovery-manager.ts	cleanupOldLoops added alongside existing cleanupOldCompletedTasks; loopRepository is optional for backward compatibility. Loop recovery itself is handled by LoopHandler.recoverStuckLoops at startup.
src/cli/commands/loop.ts	CLI command handler with pure parseLoopCreateArgs for testability. Strategy is correctly inferred from --until/--eval flags. Unknown flags return an error. Pipeline steps validated at parse time.
tests/unit/services/handlers/loop-handler.test.ts	Comprehensive 1,046-line test suite covering loop lifecycle, optimize/retry strategies, pipeline failures, recovery paths, and cancellation. 20 targeted handler tests + recovery cases.
tests/integration/task-loops.test.ts	467-line end-to-end integration tests covering retry loop, optimize loop, cancellation, and pipeline loops with real SQLite and event bus.

Sequence Diagram

sequenceDiagram
    participant CLI/MCP
    participant LoopManager
    participant EventBus
    participant LoopHandler
    participant TaskRepo
    participant LoopRepo
    participant Evaluator
    participant Worker

    CLI/MCP->>LoopManager: createLoop(request)
    LoopManager->>EventBus: emit(LoopCreated)
    EventBus->>LoopHandler: handleLoopCreated
    LoopHandler->>LoopRepo: save(loop)
    LoopHandler->>LoopHandler: startNextIteration(loop)

    rect rgb(200, 240, 200)
        note over LoopHandler: Atomic transaction
        LoopHandler->>TaskRepo: saveSync(task)
        LoopHandler->>LoopRepo: recordIterationSync(iteration)
    end

    LoopHandler->>EventBus: emit(TaskDelegated)
    EventBus->>Worker: spawn & execute task

    Worker->>EventBus: emit(TaskCompleted)
    EventBus->>LoopHandler: handleTaskTerminal

    LoopHandler->>Evaluator: evaluate(loop, taskId)
    Evaluator-->>LoopHandler: EvalResult {passed, score}

    alt Retry: passed
        rect rgb(200, 240, 200)
            note over LoopHandler: Atomic transaction
            LoopHandler->>LoopRepo: updateIterationSync(pass)
            LoopHandler->>LoopRepo: updateSync(COMPLETED)
        end
        LoopHandler->>EventBus: emit(LoopCompleted)
    else Retry: failed / Optimize: discard
        rect rgb(200, 240, 200)
            note over LoopHandler: recordAndContinue transaction
            LoopHandler->>LoopRepo: updateIterationSync(fail/discard)
            LoopHandler->>LoopRepo: updateSync(++consecutiveFailures)
        end
        LoopHandler->>EventBus: emit(LoopIterationCompleted)
        LoopHandler->>LoopHandler: checkTerminationConditions
        LoopHandler->>LoopHandler: scheduleNextIteration (with cooldown)
    end

    note over LoopHandler: On server restart
    LoopHandler->>LoopRepo: findRunningIterations → rebuildMaps
    LoopHandler->>LoopRepo: findByStatus(RUNNING) → recoverStuckLoops

Loading

_{Last reviewed commit: "test(loops): add CLI..."}

[dean0x]

Issue: execSync blocks Node.js event loop (Flagged by: Security, Performance reviewers)

The evaluateExitCondition() method uses child_process.execSync() which blocks the entire event loop for up to 60 seconds per evaluation. While your timeout prevents indefinite blocking, this prevents any other loop iterations, task completion handlers, or MCP requests from being processed during exit condition evaluation.

Fix: Replace with async exec wrapped in a Promise:

import { exec } from 'child_process';
import { promisify } from 'util';
const execAsync = promisify(exec);

private async evaluateExitCondition(loop: Loop, taskId: TaskId): Promise<EvalResult> {
  try {
    const { stdout } = await execAsync(loop.exitCondition, {
      cwd: loop.workingDirectory,
      timeout: loop.evalTimeout,
      env: { /* filtered */ },
    });
    // ... parse and return as before
  } catch (execError) {
    // ... existing error handling
  }
}

This allows the event loop to continue processing while the script executes.

[dean0x]

Issue: Undefined taskId in TaskCancellationRequested event (Security reviewer)

In cancelLoop() when cancelTasks: true, you emit TaskCancellationRequested with iteration.taskId which can be undefined (nullable field due to ON DELETE SET NULL in FK). However, TaskCancellationRequestedEvent requires taskId: TaskId (non-optional), causing type mismatch and potential runtime errors in downstream handlers.

Fix: Filter to only emit for iterations with defined taskId:

const runningIterations = iterationsResult.value.filter(
  (i) => i.status === 'running' && i.taskId !== undefined
);
for (const iteration of runningIterations) {
  await this.eventBus.emit('TaskCancellationRequested', {
    taskId: iteration.taskId!, // Safe: filtered above
    reason: `Loop ${loopId} cancelled`,
  });
}

[dean0x]

Issue: Missing index on loops.status column (Flagged by: Database, Performance reviewers)

Queries like findByStatus() and cleanupOldLoops() filter on loops.status, but no index exists. As loops accumulate, these degrade to full table scans. The schedules table already has idx_schedules_status for the same pattern.

Fix: Add two indexes to migration v10 in src/implementations/database.ts:

CREATE INDEX IF NOT EXISTS idx_loops_status ON loops(status);
CREATE INDEX IF NOT EXISTS idx_loops_cleanup ON loops(status, completed_at);

The composite index covers both status filtering and cleanup date conditions.

[dean0x]

Issue: LoopRepository.findById() returns undefined instead of null (Consistency reviewer)

TaskRepository and ScheduleRepository return Result<Task | null> and Result<Schedule | null> for not-found cases. LoopRepository returns Result<Loop | undefined>. This inconsistency in nullable patterns creates confusion across the codebase.

Fix: In src/core/interfaces.ts, update the LoopRepository interface:

findById(id: LoopId): Promise<Result<Loop | null>>;
findByIdSync(id: LoopId): Loop | null;

Then update implementations in src/implementations/loop-repository.ts to return null instead of undefined.

[dean0x]

Issue: LoopHandler at 1,106 lines approaches God Class threshold (Flagged by: Architecture, Complexity reviewers)

LoopHandler handles loop creation, iteration dispatch, exit condition evaluation, result handling, termination checks, cooldown scheduling, prompt enrichment, recovery, and map rebuilding -- at least 6 distinct responsibilities. This violates SRP and makes maintenance harder.

Suggested refactor (can be follow-up PR):

• Extract ExitConditionEvaluator interface (evaluation logic, ~60 lines)
• Extract LoopRecovery class (rebuildMaps + recoverStuckLoops, ~120 lines)
• Keep iteration dispatch and result handling in LoopHandler

This would bring each component under 400 lines with clearer single responsibility. Consider this for the next iteration.

[dean0x]

Issue: toOptimizeDirection exported from service layer (Architecture reviewer)

The MCP adapter and CLI import toOptimizeDirection from loop-manager.ts (service layer). Pure mapping functions like this belong in the domain/core layer, not inside service implementations. This creates upward dependencies from adapter/interface to concrete service classes.

Fix: Move toOptimizeDirection() to a shared utility:

// In src/utils/format.ts (alongside truncatePrompt)
export function toOptimizeDirection(str?: string): OptimizeDirection | undefined {
  // ... existing logic
}

Then update imports in mcp-adapter.ts and cli/commands/loop.ts to import from utils. (Same refactoring should apply to toMissedRunPolicy in schedule-manager.ts for consistency.)

[dean0x]

Issue: LoopRepository.findById() returns undefined instead of null (Consistency reviewer)

TaskRepository and ScheduleRepository return Result<Task | null> and Result<Schedule | null>. LoopRepository returns Result<Loop | undefined>. This inconsistency in nullable patterns creates confusion.

Fix: In src/core/interfaces.ts, update LoopRepository interface:

findById(id: LoopId): Promise<Result<Loop | null>>;
findByIdSync(id: LoopId): Loop | null;

Update src/implementations/loop-repository.ts to return null instead of undefined.

[dean0x]

Issue: toOptimizeDirection exported from service layer (Architecture reviewer)

The MCP adapter and CLI import toOptimizeDirection from loop-manager.ts (service layer). Pure mapping functions belong in the domain/core layer, not inside service implementations. This creates upward dependencies from adapter to concrete service.

Fix: Move to shared utility in src/utils/format.ts:

export function toOptimizeDirection(str?: string): OptimizeDirection | undefined {
  switch (str) {
    case 'minimize': return OptimizeDirection.MINIMIZE;
    case 'maximize': return OptimizeDirection.MAXIMIZE;
    default: return undefined;
  }
}

Then update imports in mcp-adapter.ts and cli/commands/loop.ts.

[dean0x]

Issue: Over-fetching iterations in enrichPromptWithCheckpoint() (Performance reviewer)

The method calls getIterations(loop.id, iterationNumber, 0) where iterationNumber is current count. For iteration 100, this fetches 100+ rows then does linear .find(). This grows I/O linearly with iteration count.

Fix: Only fetch the 2 most recent iterations:

const iterationsResult = await this.loopRepo.getIterations(loop.id, 2, 0);
const prevIteration = iterationsResult.value.find(
  (i) => i.iterationNumber === iterationNumber - 1
);

This reduces I/O from O(N) to O(1) per iteration.

[dean0x]

Issue: handleLoopCreate CLI function is 187 lines with ~25 cyclomatic complexity (Complexity reviewer)

The function contains a 14-branch else if chain for argument parsing (lines 53-137) with interleaved validation. This exceeds the 50-line threshold and makes it hard to add new flags.

Fix: Extract into parseLoopCreateArgs() that returns a typed options object, separating parsing from business logic. This pattern already exists in schedule.ts.

[dean0x]

Issue: LoopHandler at 1,106 lines approaches God Class threshold (Flagged by: Architecture, Complexity reviewers)

LoopHandler handles loop creation, iteration dispatch, exit condition evaluation, result handling, termination checks, cooldown scheduling, prompt enrichment, recovery, and map rebuilding -- at least 6 distinct responsibilities. This violates SRP.

Suggested refactor (can be follow-up PR):

• Extract ExitConditionEvaluator interface (evaluation logic, ~60 lines)
• Extract LoopRecovery class (rebuildMaps + recoverStuckLoops, ~120 lines)
• Keep iteration dispatch and result handling in LoopHandler

This would bring each component under 400 lines with clearer single responsibility.

[dean0x]

Code Review Summary: v0.7.0 Task Loops (PR #110)

10 reports analyzed (Security, Architecture, Performance, Complexity, Consistency, Regression, Tests, Database, Dependencies, Documentation)

---

Inline Comments Created ✓

9 blocking issues (≥80% confidence) with inline comments on specific files/lines:

1. execSync blocks event loop (95% conf, Security + Performance)
2. Undefined taskId in TaskCancellationRequested (95% conf, Security)
3. Missing loops.status index (95% conf, Database + Performance)
4. findById() returns undefined not null (92% conf, Consistency)
5. toOptimizeDirection exported from service layer (82% conf, Architecture)
6. Over-fetching iterations in checkpoint enrichment (82% conf, Performance)
7. MCP tool naming LoopStatus vs GetLoop (82% conf, Consistency)
8. CLI handleLoopCreate too complex (187 lines, 90% conf, Complexity)
9. LoopHandler at 1,106 lines (God Class, 80% conf, Architecture)

---

Medium-Confidence Findings (60-79%)

Security (Confidence 60-80%)

• No upper bound on evalTimeout (85% conf) — Add max 300000ms (5 min) to prevent resource exhaustion
• Loop exit condition inherits full process environment (80% conf) — Filter to safe variables (PATH, HOME, SHELL, BACKBEAT_*)
• Unbounded loop termination (70% conf) — Log warning when both maxIterations=0 and maxConsecutiveFailures=0 (unlimited)

Architecture (Confidence 65-85%)

• execSync hard-coded in LoopHandler violates DI (85% conf) — Extract ExitConditionEvaluator interface for testability
• updateLoop() accepts Partial<Loop> too permissive (80% conf) — Create dedicated LoopUpdate type like TaskUpdate
• RecoveryManager loopRepository optional is inconsistent (85% conf) — Make required parameter now that loops are core
• MCP adapter constructor growing (6 params) (80% conf) — Consider MCPAdapterDependencies object pattern

Performance (Confidence 65-85%)

• N+1 query in recoverStuckLoops() (85% conf) — Acceptable for startup-only path; batch if loop counts grow

Complexity (Confidence 65-92%)

• recoverStuckLoops() has 5-level nesting (92% conf) — Extract recoverStuckIteration() helper to flatten
• handleTaskTerminal() is 97 lines with duplicated failure logic (85% conf) — Route "task failed" through recordAndContinue
• extractHandlerDependencies() is 60 lines repetitive boilerplate (80% conf) — Consider batch extraction pattern
• LoopManagerService.createLoop() validation is 166 lines (82% conf) — Extract to validateCreateRequest() helper

Database (Confidence 80-85%)

• Missing CHECK constraint on eval_direction (85% conf) — Add CHECK(eval_direction IS NULL OR eval_direction IN ('minimize', 'maximize'))
• Non-atomic iteration + loop update in recordAndContinue (82% conf) — Wrap both updates in transaction, emit event after

Consistency (Confidence 80-90%)

• LoopRepository.update() signature deviates (90% conf) — Consider aligning to update(id, Partial<Loop>) pattern or document intentional choice
• ErrorCode.TASK_NOT_FOUND used for loop not-found (85% conf) — Add LOOP_NOT_FOUND error code (pre-existing pattern)
• CLAUDE.md not updated with loop files/tools (88-92% conf) — Add loop files to table, loop tools to tool list, loop handler to architecture notes, loop tables to database section
• Release notes v0.7.0 marked "Released" but package.json still 0.6.0 (85% conf) — Change to "In Progress" or bump version

Documentation (Confidence 80-95%)

• events.ts header stale (says "25" not "29" events) (95% conf) — Update comment to reflect 4 new loop events
• FEATURES.md design patterns header still says "v0.6.0" (80% conf) — Remove version or update to v0.7.0

Testing (Confidence 80-92%)

• No unit tests for 4 MCP loop handlers (~240 lines) (92% conf) — Add tests for success/validation/error paths
• No unit tests for CLI loop commands (400 lines) (88% conf) — Add tests for argument parsing and validation
• Recovery test doesn't verify recovered behavior end-to-end (80% conf) — After handler creation, emit TaskCompleted event and verify recovery
• Context enrichment test only verifies checkpoint queried, not prompt enriched (85% conf) — Capture TaskDelegated event and verify enriched prompt content
• LoopManager cancelLoop(_, _, true) not tested (82% conf) — Add test for cancelTasks=true code path

Dependencies (Confidence 95%)

• Missing --exclude='**/loop-repository.test.ts' in test:implementations (95% conf) — Add to package.json to prevent duplicate runs

---

Lower-Confidence Observations (< 60%)

To Investigate

• Dual toOptimizeDirection implementations (service vs repo) — consolidate if possible
• In-memory maps not persisted on graceful shutdown
• Pipeline iteration task creation not explicitly tested for dependency ordering
• Unbounded in-memory maps taskToLoop, pipelineTasks, cooldownTimers
• Sequential event emission in pipeline steps (could potentially parallelize with Promise.all())
• CLI loop cancel defaults differ between MCP (true) and CLI (false) for cancelTasks

---

Summary Statistics

Category	CRITICAL	HIGH	MEDIUM	LOW
Blocking (≥80% conf)	1	8	0	0
Medium Conf (60-79%)	-	-	20+	-
Pre-existing	-	-	5	-

Overall Assessment:

• ✓ Clean additive feature (zero regression risk)
• ✓ All 1,092 tests pass, Snyk clean, biome clean
• ✗ 9 actionable blocking issues (mostly architectural, testability, consistency)
• ✗ 20+ medium-confidence improvements (documentation, edge cases, refactoring)

Quality Gates: Validator ✓, Simplifier ✓, Scrutinizer ✓ (fixed 2 real bugs)

---

Reviewers

• Security: Found 3 blocking issues (execSync, undefined taskId, evalTimeout limits)
• Architecture: Found 4 blocking/should-fix issues (DI, layering, size, types)
• Performance: Found 2 blocking issues (execSync, missing indexes)
• Complexity: Found 3 blocking issues (handleLoopCreate, recoverStuckLoops, handleTaskTerminal)
• Consistency: Found 2 blocking issues (null vs undefined, tool naming)
• Database: Found 2 blocking issues (missing indexes, atomicity)
• Documentation: Found 1 CRITICAL (wrong release notes) + 4 HIGH (CLAUDE.md stale)
• Tests: Found 2 blocking gaps (MCP handlers, CLI commands untested)
• Regression: Clean ✓ — zero breaking changes detected
• Dependencies: Found 1 blocking issue (duplicate test execution)

---

Recommendation: CHANGES_REQUESTED

All 9 blocking inline comments require fixes before merge. Many are straightforward (missing indexes, null consistency, refactoring). Document intent where design deviates from existing patterns.

---

Submitted by Claude Code git-agent

[greptile-apps]

TaskDelegated emit failure orphans in-process loop

If TaskDelegated fails to emit (line 463), taskToLoop has already been populated (line 460) and the task + iteration are committed to the DB, but no handler received the event. The task stays as QUEUED indefinitely within the current process — there is no in-process retry. recoverSingleLoop will see latestIteration.taskId pointing to a non-terminal QUEUED task and conclude "will complete normally via event handler" (line 1205), so it returns without action.

The loop is stuck until server restart, where RecoveryManager.recoverQueuedTasks re-emits TaskQueued for the orphaned task and the pipeline resumes normally. For most deployments this is an acceptable safety net, but in a long-running process any transient subscriber throw during emit will silently freeze the loop.

Removing the taskToLoop entry on emit failure (and not returning silently) would allow the next recoverStuckLoops call to re-start the iteration instead:

const emitResult = await this.eventBus.emit('TaskDelegated', { task });
if (!emitResult.ok) {
  this.logger.error('Failed to emit TaskDelegated for loop iteration', emitResult.error, {
    loopId,
    iterationNumber,
    taskId: task.id,
  });
  this.taskToLoop.delete(task.id); // prevent phantom tracking
}

[greptile-apps]

Pipeline step 0 early return leaves downstream tasks registered but unrecoverable in-process

When step 0's TaskDelegated fails and the function returns early, steps 1–N have not yet been emitted (the loop exits at i === 0 before reaching them). All N tasks and the iteration record are already committed to the DB, and taskToLoop has entries for all N tasks. The pipelineTasks set is also populated.

Within the current process, step 0 is QUEUED in the DB but has no dispatcher. DependencyHandler was never notified about steps 1–N (their TaskDelegated events were never emitted either), so the dependency chain is not registered in the dependency graph. On restart, RecoveryManager will re-emit TaskQueued for step 0, the chain will be re-processed, and dependency events will be re-dispatched, so the pipeline eventually recovers.

However, if step 0's TaskDelegated emit fails, it would also be worth clearing taskToLoop entries for all steps (similar to the single-task case) so the in-memory map doesn't hold stale references until restart:

if (i === 0) {
  // Step 0 critical — clean up all tracking before returning
  for (const t of tasks) {
    this.taskToLoop.delete(t.id);
  }
  this.pipelineTasks.delete(`${loopId}:${iterationNumber}`);
  return;
}

[greptile-apps]

Silent failure on iteration-start transaction leaves loop in RUNNING forever (within process)

When the atomic runInTransaction at line 379 fails (e.g., a transient DB error), the function logs and returns — but the loop remains in RUNNING status with no new iteration created. There is no in-process path that marks the loop as FAILED or retries the start.

Recovery on the next restart handles this correctly: recoverSingleLoop finds a RUNNING loop with no new running iteration, and the terminal-status branch (latestIteration.status !== 'running') calls checkTerminationConditions + startNextIteration again. So the safety net exists.

For visibility, consider calling completeLoop here when the failure is definitively non-transient (or at least logging at error level with the loop ID so operators can correlate the stuck loop to the DB error):

if (!txResult.ok) {
  this.logger.error('Failed to start next iteration — loop will recover on restart', txResult.error, { loopId });
  // Optional: await this.completeLoop(loop, LoopStatus.FAILED, 'Failed to atomically start iteration');
  return;
}