---
id: "bug-1833"
status: "fixed"
status_updated: "2026-09-24"
status_note: ""
component: "config"
severity: "crash"
timestamp: "2026-09-20T11:00:00Z"
last_seen: "2026-09-20T11:00:00Z"
occurrences: 1
files: ["src/configs/schema/limits.schema.json"]
tags: ["xceadmin", "config-validation", "json-schema", "limit-plugin", "percent-limit", "proactive-hardening", "related-to-bug-1831", "related-to-bug-1832", "build-gotcha"]
related: ["bug-1831", "bug-1832"]
legacy: true
gitea_issue: 59
gitea_synced_status: "fixed"
---

# bug-1833: user-requested, following bug-1831/bug-1832. Nothing in xceadmin's config validation caught a…

## Description
NOT A CRASH -- proactive hardening, user-requested, following bug-1831/bug-1832. Nothing in xceadmin's config validation caught a percent-based limit's value being outside the valid 0.0-1.0 fraction range (e.g. 'value: 50, percent: true', meant to express 50% but computing as 5000% of the resource) -- both night_mem_pct in the real src/configs/limits.yaml (bug-1832) and, discovered while adding this validation, an identical stale value in the xceadmin test suite's own checked-in golden fixture (src/xceadmin/tests/fixtures/full/configs/limits.yaml) had this exact defect.

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

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

## Root cause
limits.schema.json's Limit definition had `"value": {"type": "number"}` with no range constraint at all, and no conditional (if percent then range) constraint existed anywhere in this codebase's 7 bundled JSON schemas -- confirmed no if/then usage exists in any of them prior to this fix.

## Fix
FIXED (2026-09-20). Added an if/then JSON Schema (draft 2020-12) conditional constraint to the Limit definition: `if percent == true, then value must be a number in [0.0, 1.0]`. Empirically verified against the real jsonschema==4.26.0 library this repo uses -- a violation surfaces with the exact same file/json_pointer/constraint contract validate_yaml()'s existing ValidationError already provides (constraint='maximum'/'minimum'), so zero changes were needed to validation.py's own error-reporting code. This is now enforced at real `xceadmin config build` time (deploy-ha.sh's actual cluster.bin generation path), not merely a unit-test-only check. IMPORTANT BUILD GOTCHA discovered while implementing this: this repo has TWO copies of every bundled JSON schema -- src/configs/schema/*.schema.json (the REAL canonical source) and src/xceadmin/src/xcecommon/schema_files/json/ (a checked-in mirror). meson-build.sh:104 ALWAYS overwrites the xceadmin copy from src/configs/schema/ during any real build (`cp "$SRC_DIR/configs/schema/"*.schema.json "$SCHEMA_DST/json/"`) -- editing ONLY the xceadmin-tree copy is silently discarded on the next build. Both copies were edited to stay in sync. Also fixed the same night_mem_pct value: 50 -> 0.5 defect the new constraint caught in the xceadmin test suite's own checked-in 'full' golden fixture, and regenerated its checked-in expected.bin golden artifact to match (via build.build_cluster_config()). Added 3 new tests to test_validation.py covering: reject out-of-range percent value, accept in-range percent value, and confirm a non-percent value is never range-checked regardless of magnitude.

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

## References
- Related: bug-1831, bug-1832
- Gitea: #59