Problem
When a researcher completes and produces a spec, its TaskRun status is set to awaiting_approval. When the user approves the spec via the dashboard (POST /api/spec/{issue}/approve), the spec file status changes to approved but the TaskRun record stays awaiting_approval in the database.
The supervisor's _check_already_running gate (progression.py:1100) treats awaiting_approval as a blocking condition, so the issue is permanently stuck. The supervisor logs "Spec awaiting human approval for #N (run M)" every cycle and never spawns a developer.
Root Cause
approve_spec() in sova/dashboard/services/spec_service.py updates the spec file's YAML frontmatter status but does not update the corresponding TaskRun's status to done.
The spec service knows the issue number but not the run ID. The progression engine stores the run ID in its block reason, so the mapping exists but is not used at approval time.
Fix
In approve_spec(), after updating the spec file, query the most recent TaskRun with issue_number=issue and status=awaiting_approval and update it to done. Alternatively, the spec router's approve_spec endpoint (spec.py:49) could do this since it already has access to the DB session.
Impact
All three SOVA task_queue issues (#606, #605, #564) were blocked by this. Required manual DB fix (UPDATE task_runs SET status='done' WHERE id IN (1661, 1662, 1696)).
Dependencies
None
Problem
When a researcher completes and produces a spec, its TaskRun status is set to
awaiting_approval. When the user approves the spec via the dashboard (POST /api/spec/{issue}/approve), the spec file status changes toapprovedbut the TaskRun record staysawaiting_approvalin the database.The supervisor's
_check_already_runninggate (progression.py:1100) treatsawaiting_approvalas a blocking condition, so the issue is permanently stuck. The supervisor logs "Spec awaiting human approval for #N (run M)" every cycle and never spawns a developer.Root Cause
approve_spec()insova/dashboard/services/spec_service.pyupdates the spec file's YAML frontmatter status but does not update the corresponding TaskRun's status todone.The spec service knows the issue number but not the run ID. The progression engine stores the run ID in its block reason, so the mapping exists but is not used at approval time.
Fix
In
approve_spec(), after updating the spec file, query the most recentTaskRunwithissue_number=issueandstatus=awaiting_approvaland update it todone. Alternatively, the spec router'sapprove_specendpoint (spec.py:49) could do this since it already has access to the DB session.Impact
All three SOVA task_queue issues (#606, #605, #564) were blocked by this. Required manual DB fix (
UPDATE task_runs SET status='done' WHERE id IN (1661, 1662, 1696)).Dependencies
None