pi-crew 0.2.23 → 0.2.24

package/docs/fixes/bug-020-infinite-retry-loop-needs-attention.md

@@ -0,0 +1,47 @@
+# Bug #20: Infinite Retry Loop - Mock Tasks Never Complete
+
+## Symptom
+When running tests with `PI_TEAMS_MOCK_CHILD_PI=json-success`, tasks were stuck in an infinite loop:
+- Task 01_explore ran repeatedly (100+ times)
+- Each run completed quickly but the task status stayed "needs_attention"
+- The DAG scheduler kept re-scheduling the same task
+
+## Root Cause
+The DAG-based task scheduler in `team-runner.ts` uses `completedIds` to determine which tasks are "done" and can unblock downstream tasks. However, it only considered `status === "completed"` as terminal.
+
+When a task has `yield.enabled` but the worker doesn't call `submit_result`, the task returns `status === "needs_attention"` instead of "completed". This is a terminal state (treated as such in other places), but the DAG scheduler didn't recognize it as complete.
+
+As a result:
+1. Task 01_explore returns "needs_attention"
+2. The DAG still thinks 01_explore is NOT completed
+3. The DAG returns all tasks (including 01_explore) as "ready"
+4. 01_explore gets re-scheduled, creating an infinite loop
+
+## Fix
+In `src/runtime/team-runner.ts`, change `completedIds` computation to also treat "needs_attention" as a completed state:
+
+```typescript
+// Before
+const completedIds = new Set(tasks.filter((t) => t.status === "completed").map((t) => t.id));
+
+// After
+const completedIds = new Set(tasks.filter((t) => t.status === "completed" || t.status === "needs_attention").map((t) => t.id));
+```
+
+This fix was applied in three places in team-runner.ts:
+- Line 411: DAG completion check
+- Line 422: taskResults for workflow context
+- Line 574: taskResults for phase advancement
+
+## Why This Works
+- "needs_attention" is already in the `terminalStatuses` set (used for workflow phase advancement)
+- The task graph scheduler already treats "needs_attention" as a terminal state
+- The only missing piece was the DAG-based dependency check
+
+## Verification
+Run a test with the mock:
+```bash
+PI_TEAMS_MOCK_CHILD_PI=json-success PI_TEAMS_EXECUTE_WORKERS=1 node --test test/unit/agent-runtime-files.test.ts
+```
+
+Expected: Test completes in ~3 seconds with 1 pass, 0 failures, 0 skipped.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-crew",
-  "version": "0.2.23",
+  "version": "0.2.24",
   "description": "Pi extension for coordinated AI teams, workflows, worktrees, and async task orchestration",
   "author": "baphuongna",
   "license": "MIT",

package/src/runtime/team-runner.ts

@@ -408,7 +408,7 @@ async function executeTeamRunCore(
 		// DAG-based execution plan: when tasks have explicit dependsOn, use the
 		// topological wave planner to determine ready tasks. Fall back to the
 		// existing task-graph-scheduler when no explicit deps exist (backward compat).
-		const completedIds = new Set(tasks.filter((t) => t.status === "completed").map((t) => t.id));
+		const completedIds = new Set(tasks.filter((t) => t.status === "completed" || t.status === "needs_attention").map((t) => t.id));
 		const dagReady = dagReadyTaskIds(tasks, completedIds);
 		const effectiveReady = dagReady ?? snapshot.ready;
 
@@ -419,7 +419,7 @@ async function executeTeamRunCore(
 			const wfContext: PhaseGuardContext = {
 				completedArtifacts,
 				previousPhaseStatus,
-				taskResults: tasks.filter((t) => t.status === "completed").map((t) => ({ taskId: t.id, status: t.status, outputPath: t.resultArtifact?.path })),
+				taskResults: tasks.filter((t) => t.status === "completed" || t.status === "needs_attention").map((t) => ({ taskId: t.id, status: t.status, outputPath: t.resultArtifact?.path })),
 			};
 			const preconditions = validatePhasePreconditions(wfMachine, wfContext);
 			if (!preconditions.ready) {
@@ -571,7 +571,7 @@ async function executeTeamRunCore(
 				const wfContext: PhaseGuardContext = {
 					completedArtifacts,
 					previousPhaseStatus,
-					taskResults: tasks.filter((t) => t.status === "completed").map((t) => ({ taskId: t.id, status: t.status, outputPath: t.resultArtifact?.path })),
+					taskResults: tasks.filter((t) => t.status === "completed" || t.status === "needs_attention").map((t) => ({ taskId: t.id, status: t.status, outputPath: t.resultArtifact?.path })),
 				};
 				// Determine phase transition status based on individual task outcomes
 				const phaseTasks = phaseTaskIds.map((taskId) => tasks.find((t) => t.id === taskId)).filter((t): t is NonNullable<typeof t> => t !== undefined);