Rongsong Shen
0aadb49493
core_build_job() now calls apply_job_task_count() right after its resreq parse succeeds and before core_build_schedobj() reads the resreq's task count for resreq_fp — so a freshly-submitted multi-task job's dispatched primary resreq reflects its real requested min/max task count instead of the previous always-one-task hardcode. Tracked follow-up (not blocking, see tasks.md Implementation Notes): test_repl_breakpoints_inspection.c:735 hardcodes an incidental "Tasks: min = 0, max = 0" byproduct of a fixture's parse_select() failure; now correctly reports (1,1) per Requirement 1.2. Fix folded into task 5.1's full-suite regression pass. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XYdtrEWWZfKRRGED7raEYg |
||
|---|---|---|
| .. | ||
| settings | ||
| specs | ||
| steering | ||