docs: log bug-1931/1932, init parjob-capacity-partitioning spec

- bug-1931: the parjob allocator ignores minTasks (a tasks 2..5 job pends
  although 2 slots are free).
- bug-1932: the unsatisfiable-request cache drops pend reasons on a hit
  and is unused in the simulator.
- .kiro/specs/parjob-capacity-partitioning: initialized spec with the
  candidate heuristics for capacity-driven plan generation.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

2026-10-09 08:02:00 +00:00

4 KiB

Raw Blame History

status

status_updated

status_note

component

severity

timestamp

last_seen

occurrences

files

bug-1931: xce_scheduler parjob allocator ignores minTasks: a tasks 2..5 job pends though 2 slots are free

Description

Observed: in a xce_scheduler --sim session, element [5] of an array job requesting tasks 2..5 pends although its only candidate host, pc13v, has 2 free slots (22 total, 20 in use by elements [1]-[4], 5 tasks each). The decision trace shows that only 5-task partitions are tried:

[trace] job 0-5-1791529946-0[5]  session 23  position 5  level full
  requirement single  tasks 2..5  requests mem=409600.000000 (400.00 KB)
    plan 1  hosts 1  tasks per position [5]
        host pc13v  rejected (per-host check): resource shortfall
          slots total 22 in-use 20 reserved 0 requested 5
    plan 2  hosts 2  tasks per position [3, 2]
        host pc13v  rejected (per-host check): resource shortfall
          slots total 22 in-use 20 reserved 0 requested 3
    plan 3  hosts 3  tasks per position [2, 2, 1]
        host pc13v  accepted
        ...
    plans: 5 generated, 5 tried, 0 discarded, 0 not tried; no plan could be placed
  outcome: PEND
    host pc13v: resource slots: NO_RESOURCE

Expected: a job with minTasks=2, maxTasks=5 is placed with any task count in 2..5 that fits, preferring the largest; here 2 tasks on pc13v (plan [2]). If even minTasks tasks cannot be placed, the job pends. Impact: every parallel job submitted with a task range (minTasks < maxTasks) is scheduled as if minTasks == maxTasks: it pends until maxTasks tasks fit, wasting free capacity and delaying the job indefinitely on a busy cluster. Wrong scheduling result, no crash. Found by: user review of the sim decision trace (2026-10-09).

Environment

OS: no /etc/os-release; Docker container; NixOS kernel; kernel Linux 6.18.33 x86_64
libc: not recorded: the failing xce_scheduler binary is not in this checkout (no build dir); host ldd reports glibc 2.40. The defect is in allocator logic and does not depend on libc
Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
Build: profile not recorded (asan, debug or release unknown; user's sim session); the defect is profile-independent allocator logic
Code: scheduler-framework @ a64d0846-dirty
Deployment: xce_scheduler --sim (sim session 23), one simulated worker pc13v (22 slots), queue xce, policy builtin_fcfs

Reproduction

In xce_scheduler --sim, set up one worker with 22 slots and submit an array job of at least 5 elements, each with minTasks=2, maxTasks=5 (any small mem request, e.g. 400 KB).
trace on all, then run a scheduling session: elements [1]-[4] start with 5 tasks each (20 slots used).
Element [5] pends; its trace lists only partitions of 5 tasks, never [2], [3] or [4].
Code-level check: parjob_plan_iter_init()/parjob_plan_iter_next() (src/scheduler/src/plugins/parjob_allocator.c:202-288) read only resreq->maxTasks; no allocator reads minTasks (grep -rn minTasks src/scheduler/src shows only the trace and cache-fingerprint fields).

Frequency: deterministic
Evidence: decision trace quoted above (from the user's sim session); session not saved

Root cause

TODO: required for fixed/partial

Fix