docs(accounting): say that a TRES dimension of 0 is ignored, not blocking

[nikhilsk]

Summary

The "Limit values" section of the accounting guide tells operators that a literal 0 means block all and explicitly does not mean "no limit". That is true for job counts and wall time, but not for TRES: tres_cap_breach and its account-side twin compare a dimension only when its cap is above zero, so maxtresperjob=cpu=0 leaves CPU uncapped rather than rejecting every job.

An operator following the page would expect the exact opposite, and nothing errors to correct them — the cap is simply never applied.

Approach

The detail is documented where the TRES semantics already live, as a new A TRES dimension of 0 is ignored, not "block all" subsection, with a short pointer from the 0 rule that currently overstates its reach. Both directions are cross-referenced so a reader arriving at either place learns the distinction.

The behaviour itself is left alone. It matches Slurm, and changing it would silently turn existing 0 dimensions in deployed configs into blocks.

Scope

Docs only, no behaviour change. This was raised by an automated review comment on #746; the wording it commented on is pre-existing on main and unrelated to that PR, so it is fixed here on its own rather than folded in.

Testing

Confirmed against the code that every TRES cap behaves as described: max_tres_per_job, max_tres_per_user and grp_tres all route through the zero-guarded comparison in crates/spur-core/src/qos.rs, and the account association path repeats the same guard in crates/spur-core/src/account_limits.rs. crates/spur-core/src/accounting.rs already carries a test named exceeded_caps_treats_a_zero_tres_dimension_as_uncapped asserting it.

Ran the repo's pyspelling config over docs/: the new prose adds no unknown words. The full sphinx build could not run locally — the pinned doc toolchain needs Python 3.11 and this host has 3.10 — so sphinx-build -W is left to CI.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #788   +/-   ##
=======================================
  Coverage   80.15%   80.15%           
=======================================
  Files         184      184           
  Lines       87772    87772           
=======================================
+ Hits        70348    70349    +1     
+ Misses      17424    17423    -1     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

🟡 Changes recommended

One new sentence is slightly misleading (“stop a scope from running anything”) given the recommended setting actually blocks submissions, so the wording should be tightened for accuracy.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR updates the accounting admin guide to document an important nuance in limit semantics: unlike job-count and wall-time limits, a TRES dimension set to 0 is treated as “uncapped” (ignored) rather than “block all”, aligning operator expectations with actual scheduler behavior.

Changes:

• Add a cross-reference from the general “0 means block all” rule to clarify that TRES dimensions behave differently.
• Introduce a dedicated subsection explaining that maxtres*/grptres dimensions at 0 are ignored while other dimensions in the same TRES string remain enforced.

File summaries

File	Description
docs/admin-guide/accounting.rst	Clarifies and cross-references the special-case semantics for 0 within TRES caps.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.