---
id: "bug-1831"
status: "fixed"
status_updated: "2026-09-24"
status_note: ""
component: "lib"
severity: "unknown"
timestamp: "2026-09-20T10:00:00Z"
last_seen: "2026-09-20T10:00:00Z"
occurrences: 1
files: ["src/lib/xcelimit.c"]
tags: ["scheduler", "lib", "limit-plugin", "display-formatting", "percent-limit", "info-limit", "requirement-6", "discovered-during-live-retest", "related-to-bug-1832"]
related: ["bug-1832"]
legacy: true
gitea_issue: 56
gitea_synced_status: "fixed"
---

# bug-1831: Live-verification finding (user's own retest of scheduler-sim-diagnostics Requirement 6): a…

## Description
Live-verification finding (user's own retest of scheduler-sim-diagnostics Requirement 6): a correctly-configured 20% memory limit (limits2, resname: mem, value: 0.2, percent: true) displayed as 'mem = 0.200000%' in `info limit` -- reading as 0.2 percent to a human, not the 20 percent it actually computes and enforces.

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

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

## Root cause
xce_limit_val_t.val is genuinely a 0-1 fraction when percent != 0 (confirmed end-to-end: no /100 or *100 scaling exists anywhere in the config->capnp->runtime pipeline -- src/xceadmin/src/xcecommon/mapping.py, controller.capnp's LimitValue, its C encode/decode, build_limit(), and update_limit_res_value() (plugins/limit.c) all pass the value through unchanged, multiplying it DIRECTLY against the resource's current value for capacity computation -- confirmed authoritative by the original hand-written C literal this codebase's oldest percent-based limit was migrated from, `.val = 0.2` for a documented '20% mem cap', sched.c's limit2_config, commit ecf1916d). fmt_limit()/fmt_limit_units() (src/lib/xcelimit.c) formatted the percent branch as a bare `snprintf(..., "%f%%", limit->val.val)` -- echoing the raw 0-1 fraction with a literal '%' appended, instead of converting to conventional 0-100 percent notation first.

## Fix
FIXED (2026-09-20). fmt_limit_units()'s percent branch now formats `limit->val.val * 100.0` instead of the raw `limit->val.val`, so a correctly-configured 0.2 (20%) limit displays as '20.000000%'. This is display-only -- update_limit_res_value()'s actual capacity computation was already correct and is untouched; only what a human reads changed. fmt_limit() (a thin XCE_UNITS_RAW wrapper around fmt_limit_units()) inherits this fix for its own percent-branch output too -- a deliberate, intentional behavior change from its pre-fix output for percent-based limits specifically (its 5 pre-existing direct unit tests only assert `rc > 0`, never the exact percent string, so this was safe). Updated test_limit.c's test_fmt_limit_units_percent_limit_ignores_units_mode fixture from an unrealistic `.val = 80.0` to a realistic `.val = 0.8` (80%) -- assertion text needed zero change since 0.8*100=80 either way. Updated test_repl_limit_table.c's test_info_limit_named_percent_limit_own_percentage_value_never_scaled_by_units_mode to expect the shared add_configured_percent_limit() fixture's (deliberately unchanged, .val=50.0) raw display as '5000.000000%' -- mathematically correct given that fixture's arbitrary test constant was never meant to represent a realistic percent value. RED confirmed by grepping the raw Unity testlog for :FAIL: (the aggregate meson summary masks this, a known Unity-harness quirk in this project) before the fix; GREEN confirmed after, both lib (0 Unity FAILs) and scheduler (85/85, 0 Unity FAILs) suites.

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

## References
- Related: bug-1832
- Gitea: #56