cancel-async-tasks — deadlocked its own smoke test; cut at the 180s cap mid-hang

Status: FAIL (5/6 hidden subtests) in fast__qwen3.6-35b-a3b__20260706-113104, cut by the fast-fail cap at 180s (cut@3m00s, marker exit_code 124). Baseline: FAIL @ 39s agent in the 20260703 suite — a different failure mode there: declared done without ever running the code, single-assertion near-miss. Same task, two distinct trajectories on record.

What the task wants

async run_tasks(tasks, max_concurrent) — run zero-arg async callables with bounded concurrency, and on KeyboardInterrupt cancel the in-flight tasks so their cleanup runs. The hidden tests probe the classic gotcha that asyncio.gather doesn't cancel still-queued tasks on interrupt (difficulty = "hard", tags: async/concurrency).

Trajectory (from agent/pi.txt — 4 assistant turns, ~30s of generation)

1. Turns 1–3 (~first 40s): wrote /app/run.py three times, each rewrite self-critiquing the previous in its thinking (gather → create_task → KeyboardInterrupt handling). No execution yet.
2. Turn 4: ran a self-verification bash command — a signature check plus a genuine smoke test (three 0.1s tasks, max_concurrent=2). Textbook preamble-RULE-2 behavior.
3. The smoke test deadlocked. tool_execution_start is the last transcript event before the fast_timeout marker: the remaining ~2m20s of the 180s cap burned inside the hung tool call, and pi's bash tool produced no timeout in >140s, so the model never saw any feedback.

The bug (reproduced host-side: hangs with 3 tasks / max_concurrent=2, exit 124)

Final run.py, two compounding errors:

• Double semaphore acquisition — the scheduling loop does await semaphore.acquire() per task (and never releases it) and the worker coroutine does async with semaphore: again. One permit leaks per scheduled task.
• Lost task tracking — after asyncio.wait(running, FIRST_COMPLETED) the code does running = list(done), silently dropping still-pending tasks.

Net effect: iteration 3 blocks on acquire() with 0 permits while task 2 is itself blocked on the inner acquire() — circular wait. And because each loop iteration awaits the just-created task to complete, execution is fully serialized even before the deadlock. This matches every verifier assertion: stdout.count("Task started.") == 1 where 2 were expected, test_tasks_run_concurrently failed, 5/6 subtests down (only test_run_py_file_exists passed).

Verdict attribution

The FAIL belongs to the model — the written code fails 5/6 subtests no matter when the trial ends. The fast cap changed the shape, not the verdict: uncapped, the trial would have sat in the same hang for up to the 30-minute budget. Honest caveat: the model was clearly in a verify-and-fix loop, and if pi's bash tool had timed out and returned an error it might have found the deadlock — that interaction is queued in AGENT_TODOS.md ("pi bash-tool timeout vs fast caps").

Follow-ups

• AGENT_TODOS: find pi 0.80.2's default bash-tool timeout; consider setting it below each task's fast cap so a hung self-test returns an ERROR to the model before the cap kills the trial (e2e-testable with a sleep 9999 prompt). Resolved 2026-07-07: pi has NO default bash timeout; shipped as the BASH_TOOL_TIMEOUT_DEFAULT knob (tool_call-hook injection into untimed bash calls, all 3 harnesses; ON by default at 90s since the same day, 0 or off disables) + a system-prompt note telling the model to pass larger timeouts for legitimately long commands, e2e bash-timeout case (3/3) and scripts/check_bash_timeout_logic.py. Details in AGENT_TODOS.md.
• Full narrative of the run this came from: runs/fast__qwen3.6-35b-a3b__20260706-113104/NOTES.md.