Skip to content

fix(watchdog): persist UI-saved Check Interval across restarts (#10601)#10605

Merged
mudler merged 1 commit into
masterfrom
fix/watchdog-interval-persistence-10601
Jun 30, 2026
Merged

fix(watchdog): persist UI-saved Check Interval across restarts (#10601)#10605
mudler merged 1 commit into
masterfrom
fix/watchdog-interval-persistence-10601

Conversation

@localai-bot

Copy link
Copy Markdown
Collaborator

Description

Fixes #10601.

The watchdog Check Interval configured via the Settings UI (POST /api/settings) reverted to 500ms on every container restart, even though it was correctly written to runtime_settings.json. The other watchdog settings (idle/busy enable + timeouts) persisted fine.

Root cause

NewApplicationConfig baseline-defaulted WatchDogInterval to 500ms, whereas the idle/busy timeouts default to 0. The startup loader loadRuntimeSettingsFromFile applies 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 always 500ms at that point, the guard options.WatchDogInterval == 0 never 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 0 until env/file sets them), so their guard fires.

Fix

  • Drop the non-zero baseline default in NewApplicationConfig so the interval behaves like its sibling timeouts (0 = unset, file value loads).
  • Supply the effective 500ms default at the watchdog layer instead: WithWatchdogInterval now ignores a non-positive value, preserving DefaultWatchDogOptions' 500ms and ensuring a 0 interval can never turn the watchdog loop into a busy spin.
  • Mirror the interval in the live config-file watcher alongside the idle/busy timeouts (parity for direct file edits).
  • Report the real 500ms default (not the stale "2s") from ToRuntimeSettings.

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 via NewApplicationConfig so they observe the real boot-time default):

  • a UI-saved watchdog_interval is loaded on the next startup (red before the fix - reverted to 500ms);
  • an explicit env/CLI interval is not overridden by the persisted file value.

core/config, pkg/model, core/application, and core/http/endpoints/localai suites pass; golangci-lint --new-from-merge-base=master is clean.

🤖 Generated with Claude Code

)

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]
@mudler
mudler merged commit fd8cebd into master Jun 30, 2026
59 of 63 checks passed
@mudler
mudler deleted the fix/watchdog-interval-persistence-10601 branch June 30, 2026 15:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Watchdog Check Interval not persisting

2 participants