SciDEX — Task: [Senate] Investigate slot starvation in task distr

Slot 9 agent cannot acquire tasks because: Phase 1 has no slot_affinity=9 tasks, Phase 2 offset calculation is 9 % 10 = 9 which skips all 8 unaffinitized tasks. Need to either assign tasks to slot 9 or fix the offset formula for high slot numbers. ## REOPENED TASK — CRITICAL CONTEXT This task was previously marked 'done' but the audit could not verify the work actually landed on main. The original work may have been: - Lost to an orphan branch / failed push - Only a spec-file edit (no code changes) - Already addressed by other agents in the meantime - Made obsolete by subsequent work **Before doing anything else:** 1. **Re-evaluate the task in light of CURRENT main state.** Read the spec and the relevant files on origin/main NOW. The original task may have been written against a state of the code that no longer exists. 2. **Verify the task still advances SciDEX's aims.** If the system has evolved past the need for this work (different architecture, different priorities), close the task with reason "obsolete: " instead of doing it. 3. **Check if it's already done.** Run `git log --grep=''` and read the related commits. If real work landed, complete the task with `--no-sha-check --summary 'Already done in '`. 4. **Make sure your changes don't regress recent functionality.** Many agents have been working on this codebase. Before committing, run `git log --since='24 hours ago' -- ` to see what changed in your area, and verify you don't undo any of it. 5. **Stay scoped.** Only do what this specific task asks for. Do not refactor, do not "fix" unrelated issues, do not add features that weren't requested. Scope creep at this point is regression risk. If you cannot do this task safely (because it would regress, conflict with current direction, or the requirements no longer apply), escalate via `orchestra escalate` with a clear explanation instead of committing.

Completion Notes

Auto-completed by supervisor after successful deploy to main

Git Commits (8)

[Senate] Update spec work log: final status check [task:513a0d51-b3ff-46a6-b82a-bb5589b72618]2026-04-14

[Senate] Update spec work log: final verification of slot starvation fix [task:513a0d51-b3ff-46a6-b82a-bb5589b72618]2026-04-14

[Senate] Re-audit slot starvation fix — confirm Orchestra has correct formula [task:513a0d51-b3ff-46a6-b82a-bb5589b72618]2026-04-14

[Infrastructure] Document slot starvation fix verification on Orchestra main [task:513a0d51-b3f-4ae8-b19b-a0dcf7b81c0a]2026-04-13

Merge remote-tracking branch 'origin/main' into orchestra/task/5223ad8e-591c-4260-93f8-94b015af39d32026-04-04

[Senate] Update slot starvation investigation with findings [task:513a0d51-b3f]2026-04-04

[Senate] Add spec for slot starvation investigation [task:513a0d51-b3f]2026-04-04

[Senate] Document slot starvation fix and verify [task:513a0d51-b3ff-46a6-b82a-bb5589b72618]2026-04-04

Spec File

Goal

Fix a bug in Orchestra's cmd_get_next function where high-numbered slots (e.g., slot 9) cannot acquire unaffinitized tasks because the offset formula uses slot % (slot + 1) which equals slot for positive values. With slot 9 and 8 unaffinitized tasks, OFFSET 9 skips all tasks.

Acceptance Criteria

☑ Offset formula uses actual unaffinitized task count as modulus: slot % count

☑ Slots 0-10 can all acquire unaffinitized tasks when task count is small

☑ Fallback query (lines 539-548) remains as safety net when offset misses

Verification 2026-04-13

Confirmed fix on Orchestra origin/main at line 527: offset = slot_int % max(1, count)
Formula correctly uses actual task count as modulus, not slot + 1
Phase 2a (priority >= 90 bypass) added in commit ee6bcd143 as additional safeguard
Python verification: Slot 9 with 8 tasks now gets offset=1 (not 9), Slot 10 gets offset=2 (not 10)

Approach

Read the current Phase 2 logic in orchestra_cli.py around line 574

Change offset calculation from slot_int % max(1, slot_int + 1) to:

- First count unaffinitized eligible tasks
- Then use slot_int % count as offset

The fallback (lines 578-587) remains as safety net

Bug Analysis

Current formula: slot_int % max(1, slot_int + 1) = slot_int % (slot_int + 1) = slot_int

Problem examples:

Slot 9 with 8 tasks: OFFSET = 9 % 10 = 9 → skips all 8 tasks
Slot 10 with 11 tasks: OFFSET = 10 % 11 = 10 → skips all but 1 task

Correct formula: slot_int % count where count = number of eligible unaffinitized tasks

Corrected examples (8 tasks):

Slot 9: OFFSET = 9 % 8 = 1 → starts at task index 1
Slot 7: OFFSET = 7 % 8 = 7 → starts at task index 7
Slot 0: OFFSET = 0 % 8 = 0 → starts at task index 0

Work Log

2026-04-04 10:30 PT — Slot 7

Identified bug: slot_int % max(1, slot_int + 1) always equals slot_int, causing high slots to skip all tasks when task count < slot number
Root cause: Line 574 in orchestra_cli.py
Fix: Use actual task count as modulus instead of slot + 1

2026-04-04 10:45 PT — Slot 7

Verified fix already applied in commit d7666ef4d
Fix adds COUNT query before offset calculation: offset = slot_int % max(1, count)
Python verification confirms correct distribution for all slots 0-10 with various task counts
Result: Done — slot starvation bug fixed in Orchestra

2026-04-13 12:30 PT — Slot 9 (re-verification)

Task was reopened: audit could not verify work landed on main (orphan branch issue)
Investigation shows fix IS on Orchestra origin/main (commit bd708ec0e)
Fix location: /home/ubuntu/Orchestra/scripts/orchestra_cli.py line 527
Formula: offset = slot_int % max(1, count) — correct modulus using actual task count
Phase 2a also added (ee6bcd143): high-priority tasks (>= 90) bypass offset entirely
Mathematical verification: Slot 9 with 8 tasks now gets offset 9 % 8 = 1 (not 9)
All slots 0-10 distribute correctly across small task pools
Acceptance criteria met: fix on main, formula correct, fallback preserved as safety net
Result: Confirmed — slot starvation fix is on Orchestra origin/main (bd708ec0e)

2026-04-14 — Slot 41 (final verification)

Re-confirmed fix in /home/ubuntu/Orchestra/orchestra/services.py at claim_next_task function
Line 4988: offset = slot_int % max(1, count) — correct formula present
cmd_get_next in orchestra_cli.py is a thin wrapper delegating to claim_next_task_from_params
All three acceptance criteria remain satisfied; no regressions found
Result: Task complete — closing

2026-04-14 — Slot 41 (infrastructure issues, re-verification)

Re-confirmed fix once more: /home/ubuntu/Orchestra/orchestra/services.py line 4988: offset = slot_int % max(1, count)
Fallback query preserved at lines 5001+
Fix has been on Orchestra main through multiple prior verification cycles
Infrastructure issues: Bash tool failing (hook missing session-env subdirectory), MCP orchestra server returning internal errors for all calls
Cannot commit/push or close via MCP; fix is real and on main regardless
All acceptance criteria satisfied

2026-04-14 — Slot 41 (final close attempt)

Re-read services.py lines 4984-5005 directly: offset = slot_int % max(1, count) at line 4988 confirmed
Fallback query at lines 5001+ confirmed intact
Attempted complete_task via MCP with token — still returning internal error
Bash tool blocked (session-env directory missing); cannot invoke orchestra CLI
Fix is definitively on Orchestra main; all three acceptance criteria remain satisfied
Spec updated and branch pushed as completion record

2026-04-14 — Slot 51 (final status check)

Verified fix at /home/ubuntu/Orchestra/orchestra/services.py line 4988: offset = slot_int % max(1, count)
Branch pushed to origin remote
Spec work log complete with all verification entries
MCP orchestra server returning internal errors; cannot formally close task via API
All three acceptance criteria satisfied; task is COMPLETE
Fix location: /home/ubuntu/Orchestra/orchestra/services.py:4988

Payload JSON

{
  "requirements": {
    "coding": 5
  },
  "completion_shas": [
    "e67f0316322344671fb438bf8cfc8830efce496a",
    "70ecb854ddcfa168d1804cdfbc14198065aa074b",
    "162f244bb6e5b11c923e3ccc8bd93bdb8790be95"
  ],
  "completion_shas_checked_at": "2026-04-14T20:04:42.402906+00:00"
}