mirror of
https://github.com/pyMC-dev/pyMC_Repeater.git
synced 2026-10-31 04:01:59 +01:00
fabric.repeat_on_ingress and fabric.origin_tx are only checked when build_radio_stack assembles the radios. Everything that writes config -- the UI, a backup restore, a hand edit -- ran long before that, so a combination with no defined meaning was accepted, written to disk, and refused only at the next restart, by which point the caller that could have fixed it was gone. validate_fabric_config runs those same checks against a whole config mapping. config_import calls it before the section-merge loop touches self.config, and validate_config reports the result as a fabric error, so the pre-restart check names the thing that will block the restart; it covered no fabric or radios key at all before. Checking before the loop rather than inside it is the point. The loop merges section by section, so a rejection partway through would leave half an import applied to a running node. A malformed radios section is refused the same way, ahead of everything, since the loop's own check for it ran only once the earlier sections were already in. That also keeps the message about the real problem: a non-list radios previously reached the fan-out check as "one radio" and came back as a radio-count error. The merge the preflight models has to match the loop exactly, or it rejects configs the daemon would accept. A dict fabric merges by update; anything else replaces the section wholesale, including fabric: null. That last case is how an operator clears fan-out left invalid by an older build, so validating the old section there would reject the one import that repairs the node. tx_mode is checked only where the daemon applies it. _apply_fabric_tx_mode -- the thing that raises on an unknown mode -- runs for a non-empty radios list or use_fabric and nowhere else, so a legacy single-radio node carrying a stale or misspelled tx_mode boots fine today. Refusing its unrelated imports would be this check inventing a failure rather than reporting one.