Fixed a v3.0.2-era validator regression that prevented users from enabling the ntfy push-notification feature v3.0.2 shipped. Found by user during v3.0.7 dogfooding: after navigating to the new /config → Updates tab and toggling "Send ntfy push notification," he flipped over to the Notifications tab (per the v3.0.7 helper text on the Updates tab explicitly instructing this) to enable notifications.events.update_available — the second half of the two-key gate every ntfy event uses. Save returned 1 validation error(s) with message "Unknown event type (known: capacity_low, capacity_recovered, daily_summary, emergency_squawk, new_record, receiver_offline, receiver_recovered, special_aircraft, watchlist_hit)". Root cause: when v3.0.2 added update_available to the ntfy event registry, it correctly updated notifier.py's KNOWN_EVENTS set (the runtime-side gate that decides whether the notifier accepts a notify(event="update_available", ...) call) but missed the parallel known_events set in config_validator.py at line 612 (the save-time gate that decides whether notifications.events.update_available: true is a valid YAML key). Two parallel sources of truth for the "what events exist" question, only one updated. The runtime would have fired the notification correctly if the validator had let the user save the config to enable it — but the validator gated the save, so the notification never had a chance to fire.
The fix is a one-line addition to the known_events set in config_validator.py's _validate_notifications() block, with a comment explaining the v3.0.8 archaeology so the next time someone adds a new event type, they remember to update both lists. Net diff: ~10 lines (the literal addition plus the explanatory comment).
The deeper lesson: any new ntfy event type now needs updates in three places — notifier.py KNOWN_EVENTS (runtime), config_validator.py known_events (save-time validation), and config.yaml.example notifications.events block (default config). The first two should arguably be unified to a single source of truth, possibly by importing KNOWN_EVENTS from notifier.py into config_validator.py rather than maintaining a parallel set. Filed for future polish; not in v3.0.8's scope.
Verification path: users on v3.0.7 who tried to enable update_available push notifications and hit "Unknown event type" can now save successfully after applying v3.0.8. The feature was fully implemented in v3.0.2 (notifier registry, transition detection, ntfy route mapping, cooldown — all working) and fully reachable in the UI in v3.0.7 (Updates tab + Notifications tab), but blocked at the validator from v3.0.2 through v3.0.7. v3.0.8 is when the feature actually becomes enable-able by an end user.
The other UX gap surfaced here, filed for future polish: the /config status bar shows "N validation error(s)" without surfacing which error or which field. Per-field inline error display does exist, but only renders on the tab containing the error, and only if the user happens to be looking at that field. Auto-switch-to-error-tab logic exists too but only fires when the current tab has zero errors. Net effect: a user editing one tab who hits a validation error on a different field on a different tab can see "1 validation error(s)" without any indication of where to look. Two improvements worth queuing: (1) include the first error's path-and-message in the status bar text (e.g. "1 validation error: notifications.events.update_available — Unknown event type"), and (2) make the count clickable to scroll to / focus the first error field. Both are small (~30 lines each); both meaningfully improve the debugging experience. Filed for v3.0.9+.