Repository navigation
Lite loads three settings keys it gives the user no way to set #2393
Description
Found while working #2391, which was the same shape: a knob wired end to end everywhere except the place a user could reach it.
Lite's App.LoadAlertSettings reads three keys from settings.json that no Lite control ever sets:
| key | static | default | clamp on read | Darling Viewer |
|---|---|---|---|---|
analysis_notify_cooldown_minutes |
AnalysisNotifyCooldownMinutes |
360 | 30–10080 | has a box (AnalysisNotifyCooldownBox) |
analysis_timeout_seconds |
AnalysisTimeoutSeconds |
120 | 30–600 | no |
check_for_updates_on_startup |
CheckForUpdatesOnStartup |
true | — | n/a |
This is milder than #2391 in one specific way, and it is worth stating so nobody fixes the wrong thing: these do persist. Lite's writer parses the existing settings.json into a JsonNode and mutates it, so a key it never touches survives a save. Hand-editing works and sticks. The gap is discoverability, not data loss.
Still worth closing, in descending order of how much it actually matters:
analysis_notify_cooldown_minutes is the real one — it is the re-notify gap per finding, so it is the knob a Lite user reaches for when analysis notifications are too chatty, and the Darling Viewer already exposes it. That is a straight parity gap.
analysis_timeout_seconds is a per-server analysis timeout. Neither SKU exposes it, so this is a question of whether it should be exposed at all rather than a parity gap.
check_for_updates_on_startup has no UI on either SKU. It is a privacy-adjacent default-on behavior, which is usually an argument for a visible switch, but that is a product call rather than a defect.
AlertSettingsControlWiringTests in #2392 deliberately does not assert loader/writer symmetry, so it will not flag these — symmetry is not the invariant (see above). Anything here needs a decision first, not a guard.
Activity
erikdarlingdata commentedon Aug 21, 2026
Fixed on
devby #2408, which exposesanalysis_notify_cooldown_minutesin Lite's Settings window — the one of the three that was a genuine parity gap, since the Darling Viewer has hadAnalysisNotifyCooldownBoxall along.The other two turned out not to be parity gaps at all, and each is worse than "missing a control":
analysis_timeout_seconds→ #2412. It should not be surfaced as it stands, because the name promises something the code does not do.CollectionBackgroundServicerunsTask.WhenAny(analyzeTask, Task.Delay(timeout))and, on timeout, logs andcontinues — nothing is cancelled,AnalyzeAsyncruns on and persists its findings regardless. Raising the knob would only make the loop wait longer for a result it was going to keep anyway. Worse, the in-flight guard is released only on true completion, so an analysis that never finishes leaves that server's marker set permanently and the server is silently skipped on every later cycle with one log line to show for it. That is the actual bug and it has its own issue now.check_for_updates_on_startup→ #2413. Not a parity gap either — Darling has no equivalent, being a service rather than a self-updating desktop app. It is a default-on outbound call to github.com five seconds after every launch, turn-off-able only by hand-editing a key that appears in no sample file and no documentation. That deserves a visible switch on its own merits rather than as a settings-parity chore, and it belongs in General beside "Minimize to tray" rather than in the alert block.One note on the shape of #2408, since it looks like an omission: the new box is deliberately not gated in
UpdateAlertControlStates. Analysis notifications do not depend on the master alerts switch, neither app gatesAnalysisIntervalBoxorAnalysisNotifySeverityBoxthere, and the drift guard's own regex (\bAlert\w*Box\b) cannot match anAnalysis*Box— which is why the Darling Viewer passes today with its cooldown box ungated too. Gating it would advertise a dependency the engine does not have.Remove files that belong to other branches from this one
Give Lite a box for the analysis re-notify cooldown (erikdarlingdata#…
Make the analysis timeout mean something, and stop a wedged server go…