fix(watchdog): persist UI-saved Check Interval across restarts (#10601)#10605
Merged
Conversation
) The watchdog Check Interval saved via /api/settings reverted to 500ms on every restart, while the idle/busy timeouts persisted correctly. Root cause: NewApplicationConfig baseline-defaulted WatchDogInterval to 500ms, whereas the idle/busy timeouts default to 0. The startup loader (loadRuntimeSettingsFromFile) applies a persisted runtime_settings.json value only when the field is still at its zero default - its heuristic for "this wasn't set by an env var". Because the interval was always 500ms at that point, the loader never read the persisted value back, so the saved interval was silently discarded on each boot. Fix: drop the non-zero baseline default so the interval behaves like the sibling timeouts (0 = unset). The effective 500ms default is now supplied at the watchdog layer: WithWatchdogInterval ignores a non-positive value so DefaultWatchDogOptions' 500ms is preserved (and a 0 interval can never turn the watchdog loop into a busy spin). Also mirror the interval in the live config file watcher alongside idle/busy, and report the real 500ms default (not the stale "2s") from ToRuntimeSettings. Signed-off-by: Ettore Di Giacinto <mudler@localai.io> Assisted-by: Claude:claude-opus-4-8 [Claude Code]
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fixes #10601.
The watchdog Check Interval configured via the Settings UI (
POST /api/settings) reverted to500mson every container restart, even though it was correctly written toruntime_settings.json. The other watchdog settings (idle/busy enable + timeouts) persisted fine.Root cause
NewApplicationConfigbaseline-defaultedWatchDogIntervalto500ms, whereas the idle/busy timeouts default to0. The startup loaderloadRuntimeSettingsFromFileapplies a persisted value only when the field is still at its zero default - the heuristic it uses to mean "this wasn't set by an env var" (so env/CLI keeps precedence over the file). Because the interval was always500msat that point, the guardoptions.WatchDogInterval == 0never held, the persisted value was never read back, and the interval reset to the default on every boot.The idle/busy timeouts work precisely because they are not baseline-defaulted (they stay
0until env/file sets them), so their guard fires.Fix
NewApplicationConfigso the interval behaves like its sibling timeouts (0= unset, file value loads).500msdefault at the watchdog layer instead:WithWatchdogIntervalnow ignores a non-positive value, preservingDefaultWatchDogOptions'500msand ensuring a0interval can never turn the watchdog loop into a busy spin.500msdefault (not the stale"2s") fromToRuntimeSettings.Env/CLI precedence is preserved: an explicitly set interval still wins over the persisted file value, consistent with the idle/busy timeouts.
Tests
Added two specs in
core/application/runtime_settings_branding_test.go(constructed viaNewApplicationConfigso they observe the real boot-time default):watchdog_intervalis loaded on the next startup (red before the fix - reverted to 500ms);core/config,pkg/model,core/application, andcore/http/endpoints/localaisuites pass;golangci-lint --new-from-merge-base=masteris clean.🤖 Generated with Claude Code