---
id: "bug-1832"
status: "fixed"
status_updated: "2026-09-24"
status_note: ""
component: "config"
severity: "unknown"
timestamp: "2026-09-20T10:00:00Z"
last_seen: "2026-09-20T10:00:00Z"
occurrences: 1
files: ["src/configs/limits.yaml"]
tags: ["scheduler", "config", "limit-plugin", "percent-limit", "night_mem_pct", "config-authoring-bug", "discovered-during-live-retest", "related-to-bug-1831", "behavior-change"]
related: ["bug-1831"]
legacy: true
gitea_issue: 58
gitea_synced_status: "fixed"
---

# bug-1832: src/configs/limits.yaml's night_mem_pct limit (resname: mem, value: 50, percent: true) is…

## Description
src/configs/limits.yaml's night_mem_pct limit (resname: mem, value: 50, percent: true) is functionally dead -- it can never bind or deny any job, since its actual computed capacity is 50x (5000%) the resource's current value, not 50% of it. Surfaced while investigating bug-1831's percent-display discrepancy.

## Environment
_Not recorded (migrated from buglog.json)._

## Reproduction
_Not recorded (migrated from buglog.json)._

## Root cause
xce_limit_val_t.val is a 0-1 fraction convention when percent is set (see bug-1831's root_cause for full pipeline trace -- no /100 scaling exists anywhere). night_mem_pct was authored directly in YAML for a docs/example config (commit a1478510, 'docs(admin-config-tool): commit spec docs and example configs') with no C-literal ancestry to cross-check against, unlike limits2 (migrated verbatim from a hand-written C literal `.val = 0.2` for '20% mem cap', sched.c's limit2_config) -- so it used the human-intuitive but incorrect 0-100 scale convention ('50' meaning 50%) instead of the pipeline's real 0-1 fraction convention.

## Fix
FIXED (2026-09-20, user-directed). Changed limits.yaml's night_mem_pct value from 50 to 0.5, matching the 0-1 fraction convention -- it now correctly computes and enforces a genuine 50% cap on the night queue's mem usage instead of a non-binding 5000% one. This is a production config behavior change, not merely a display fix: night_mem_pct will now actually constrain job admission for the first time in any real deployment using this config, where previously it silently did nothing.

## Verification
_Not recorded (migrated from buglog.json)._

## References
- Related: bug-1831
- Gitea: #58