Phase 4b fans out one issue-writer agent per issue with no concurrency cap (host OOM) #174

Summary

swe-planner.plan Phase 4b starts one run_issue_writer call per issue in a single unbounded asyncio.gather (swe_af/app.py, the writer_tasks block). The replanner's writer pass has the same shape (_write_issue_files_for_replan in swe_af/execution/dag_executor.py).

Each writer is a full harness call, so each one spawns its own provider CLI subprocess. Peak process count and memory therefore scale with the size of the plan. max_concurrent_issues does not apply here — it only bounds DAG level execution.

Steps to Reproduce

1. Run swe-planner.build for a goal the sprint planner decomposes into many issues (observed: 35).
2. Watch Phase 4b and the host process count (ps -Ao pid,ppid,rss,command).

Expected Behavior

Writer fan-out is bounded by a configurable limit that does not depend on plan size.

Actual Behavior

All writers start at once. From the control plane's workflow_executions table for the observed run:

• 35 run_issue_writer executions started between 13:43:41.350 and 13:43:41.600 — a 250 ms window.
• Input payload was ~126–128 KB per writer.
• All 35 were live when the 8 GB host rebooted ~2.5 minutes later; they were later recorded as agent_restart_orphaned.

On the same machine, a single agent CLI subprocess measured 85–235 MB RSS, so 35 concurrent writers is roughly 3–8 GB before the Python node itself.

Environment

• OS: macOS (Apple Silicon), 8 GB RAM
• Python: 3.13
• AI provider: claude_code runtime (claude-agent-sdk 0.1.20)
• Deployment: local control plane + node
• SWE-AF: main @ da78a77, agentfield 0.1.145

Logs or Trace

exec_20261101_214341_*  run_issue_writer  failed  started 13:43:41.35x  input_size 126567..128622
... 35 rows, all started within 250 ms, all failed with:
agent_restart_orphaned: previous instance ... is gone and the execution did not complete within the drain window

A cap of a few concurrent writers would keep the wall clock close to the current behaviour for the common case (writers are short and I/O-bound on the model API) while bounding peak process count.