ci: let Phoenix SLURM jobs wait for a node up to the job timeout (queue cap default 0) - #1770
Conversation
…ue cap 0) Revert the 4h SLURM_MAX_QUEUE_SECONDS cap (#1763) back to the prior behavior: on Phoenix's preemptible 'embers' QOS jobs routinely need most of the 480m job-timeout window to backfill onto a free GPU node. Capping the queue wait at 4h turned ordinary queue pressure into red CI that had to be rerun repeatedly. Default to 0 (wait indefinitely; the 480m job timeout is the backstop), while leaving SLURM_MAX_QUEUE_SECONDS available for opt-in on non-preemptible queues.
There was a problem hiding this comment.
Pull request overview
This PR adjusts Phoenix CI’s SLURM monitoring behavior to restore the pre-#1763 default: do not cap how long a job may remain queued, and instead rely on the GitHub Actions job-level timeout-minutes as the backstop. This targets queue-heavy/preemptible Phoenix runs where a 4-hour queue cap turns normal PENDING delays into CI failures.
Changes:
- Change the default
SLURM_MAX_QUEUE_SECONDSfrom14400(4h) to0(no queue-wait cap). - Update the inline documentation to clarify the rationale and how to opt into an earlier cutoff via
SLURM_MAX_QUEUE_SECONDS>0.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1770 +/- ##
=======================================
Coverage 61.67% 61.67%
=======================================
Files 84 84
Lines 21619 21619
Branches 3196 3196
=======================================
Hits 13334 13334
Misses 6093 6093
Partials 2192 2192 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
What
Restores the pre-#1763 behavior: a SLURM job waits for a compute node up to the job-level
timeout-minutes(480m / 8h) instead of being cut off after 4h.Changes only the default of
SLURM_MAX_QUEUE_SECONDSinmonitor_slurm_job.shfrom14400(4h) to0(wait indefinitely — the 480m job timeout is the backstop). The enforcement loop already treats0as "no cap," so this is a one-value change; #1763's build+test-in-one-allocation improvement is untouched.Why
On Phoenix's preemptible embers QOS, jobs routinely sit
PENDINGfor hours and need most of the 8h window to backfill onto a free GPU node. The 4h cap turned ordinary queue pressure into red CI:These aren't test or code failures — just the free QOS not landing a node in 4h — but they block PRs and have to be rerun repeatedly. A month ago, with only the 8h job timeout as the limit, Phoenix jobs usually got a node and ran. This brings that back.
SLURM_MAX_QUEUE_SECONDSremains available (set it>0) to opt into an earlier cutoff on non-preemptible schedulers where a long PENDING genuinely signals a problem.