3f8a5e6839
The executor's no-fn_task_done retry loop has two reclaim signals (retryAbortedDueToReclaim=true): (1) pre-retry liveness recheck where the task DB shows worktree/branch was cleared, and (2) session-start failure because the worktree path no longer exists. Both are engine self-heal situations triggered by FN-4546 stale-active-branch reclaim, FN-4742 self-healing removals, or related housekeeping paths — the agent never got a fair retry attempt. Previously these surfaced as task status=failed with error 'Worktree/branch reclaimed during no-fn_task_done retry — requeueing', fired onError, and burned the taskDoneRetryCount budget. Three legitimate problems followed: tasks accumulated spurious failures in the UI, the exhausted-budget branch escalated reclaimed tasks to in-review instead of retrying, and the noise masked the underlying worktree-removal regression (FN-4811). Now the reclaim branch silently: - clears stale worktree/branch metadata so the next pickup creates a fresh worktree - requeues to todo with preserveProgress - logs an informational 'engine self-heal, no failure' line - does NOT set status=failed, does NOT bump taskDoneRetryCount, does NOT call onError The genuine 'agent finished without calling fn_task_done after N retries' exhaustion path (retryAbortedDueToReclaim=false) is unchanged. Tests updated in packages/engine/src/__tests__/reliability-interactions/executor-no-task-done-vs-worktree-reclaim.test.ts to assert the new silent-recovery contract on all three reclaim paths. Fusion-Task-Id: FN-4806
694 B
694 B
@runfusion/fusion
| @runfusion/fusion |
|---|
| patch |
fix(FN-4806): silently recover when worktree/branch reclaimed mid-retry
When the executor's no-fn_task_done retry loop detects that a task's worktree or branch was reclaimed by an engine-side housekeeping path (FN-4546 stale-active-branch reclaim, FN-4742 self-healing removals, session-start unusable-worktree), it now requeues the task to todo silently with preserved progress. The task is no longer marked failed, taskDoneRetryCount is no longer burned, and onError is no longer surfaced — this is engine self-heal, not an agent failure. The genuine "agent finished without calling fn_task_done after N retries" exhaustion path is unchanged.