Severity: high | Category: correctness | Phase: P0.15
Problem
cancel_batch/stop_batch write status=CANCELLED, but the executing loop's in-memory batch stays RUNNING and every task completion does a whole-row INSERT OR REPLACE INTO batch_runs ... batch.status — overwriting the cancel. The next loop iteration reads RUNNING and keeps launching tasks (spending LLM tokens). Force-stop only SIGTERMs the current subprocess; the loop starts the next.
Evidence
codeframe/core/conductor.py:2210 (INSERT OR REPLACE), :820/:858 (cancel/stop)
Acceptance criteria
_save_batch refuses to downgrade CANCELLED→RUNNING (re-read status, or persist only the results column from workers).
- CANCELLED is preserved as the final status when the loop exits due to cancellation.
- Test: cancel during an in-flight task stops subsequent tasks from starting.
Dependencies
None
Filed from the SaaS launch-readiness audit. Atomic: one developer, one session. Work order: strictly P0.1 → P3.12 (no forward dependencies).
Severity: high | Category: correctness | Phase: P0.15
Problem
cancel_batch/stop_batchwrite status=CANCELLED, but the executing loop's in-memorybatchstays RUNNING and every task completion does a whole-rowINSERT OR REPLACE INTO batch_runs ... batch.status— overwriting the cancel. The next loop iteration reads RUNNING and keeps launching tasks (spending LLM tokens). Force-stop only SIGTERMs the current subprocess; the loop starts the next.Evidence
codeframe/core/conductor.py:2210(INSERT OR REPLACE),:820/:858(cancel/stop)Acceptance criteria
_save_batchrefuses to downgrade CANCELLED→RUNNING (re-read status, or persist only the results column from workers).Dependencies
None
Filed from the SaaS launch-readiness audit. Atomic: one developer, one session. Work order: strictly P0.1 → P3.12 (no forward dependencies).