Automation scripts fail in frustrating ways when configuration is wrong — a missing API key causes a crypticDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/iFamishedX/HungerLib/llms.txt
Use this file to discover all available pages before exploring further.
AttributeError deep inside a restart loop, or a mistyped YAML value is silently coerced and produces subtly incorrect behavior. HungerLib’s Validator class solves this by running structured checks on your config dataclasses before your script does any real work. It distinguishes between missing required fields (which should halt execution), type mismatches (which indicate likely bugs), fields still using their fallback value (informational), and missing recommended keys (advisory) — and it raises different exception types for each category so your script can respond appropriately.
Error Hierarchy
All validation exceptions inherit fromValidationError, which carries structured data alongside the human-readable report string.
FatalError
One or more required fields are missing from the config file or are still using their declared fallback value. Script execution should not continue.
TypeMismatchError
A field’s value does not match the type declared in the dataclass annotation. Raised only when no
FatalError conditions exist.FallbackError
A recommended field is present in the YAML but its value matches the fallback. Non-fatal — the script can continue, but the operator should be informed.
RecommendedError
A recommended key is absent from the config file entirely. Advisory only — the fallback value is in use and the script can proceed.
Validator.run() raises only the highest-priority exception found across all validated configs. If both FatalError and FallbackError conditions exist, only FatalError is raised — its .fallbacks attribute still contains the lower-priority findings.
Defining Rules
Config schemas declare their validation rules via arules class attribute — a SimpleNamespace where each attribute name matches a dataclass field and its value is "required", "recommended", or "optional".
rules default to "optional" and are not checked by check_field. The rules namespace is read at runtime by Validator._rule() — no metaclass magic or registration is required.
loadConfig populates each field from the YAML path stored in the dataclass default. If a YAML key is absent, loadConfig falls back to the fallbacks object defined in the same module. The Validator then inspects both .raw and .fallbacks attributes that loadConfig attaches to the config instance — do not strip these attributes before running validation.Subclassing Validator
Create a subclass and overridevalidate_schema to define which fields to check:
validate_schema is called once per config object passed to run(). You can call check_field and validate_key_types in any order and as many times as needed — results accumulate across all calls and are summarized in the final report.
Running Validation
run() accepts multiple config objects: v.run(cfg_a, cfg_b). It calls validate_schema on each in order, accumulates all findings, and raises a single exception summarizing everything.
Constructor
Message appended to
errors when a required field’s YAML key is absent. Supports {field}.Message appended to
recommended when a recommended field’s YAML key is absent. Supports {field}, {fallback}.Message appended to
errors when a required field’s value equals its declared fallback. Supports {field}, {value}.Message appended to
fallbacks when a recommended field’s value equals its declared fallback. Supports {field}, {value}.Message appended to
errors when a field’s runtime type doesn’t match the dataclass annotation. Supports {schema}, {field}, {expected}, {actual}, {value}.Key Methods
check_field
loadConfig-produced config instance. It reads the field’s rule from obj.__class__.rules, compares the live value against the fallback value on obj.fallbacks, and checks whether the raw YAML key was present on obj.raw. Results are accumulated into self.errors, self.fallbacks, or self.recommended depending on the rule and finding.
A config object produced by
loadConfig. Must have .raw and .fallbacks attributes attached.The field name to inspect. Must match an attribute on
obj.validate_key_types
schema dataclass and compares each field’s runtime value type against the declared annotation using isinstance. Fields whose names begin with __ are skipped. Any mismatch appends a formatted message to self.errors.
The config object to inspect.
The dataclass class (not instance) whose field annotations define the expected types. Typically the same class used with
loadConfig.validate_schema
run().
run
validate_schema on each config, then raises the highest-priority exception found. Returns the report string "all configs valid" if no issues were found.
format_report
errors, recommended, fallbacks, and warnings. Returns "all configs valid" if all lists are empty. Called automatically by run() before raising — you rarely need to call this directly.