Repository navigation
Storage health hides archive failures and recovered write failures #1279
Description
Activity
This is in the code that
v0.132.0-beta.1is running./api/healthincludeshistory_storage.maintenancewith phase, last success, last failure and failure count. A failed maintenance run marks health degraded. The next successful run clears the current error and returns health to ok, and keepslast_failure_errorand the failure count. A recovered history commit clearslast_errorand keepscommit_failuresandlast_failure_error.TestHealthShowsFailedArchiveAndRecoveryandTestHealthShowsRejectedPrimaryHistorypassed. On homelab-rpi after the native switch the writer shows two recoveredSQLITE_BUSYcommits and later successful writes, which is this diagnostic, not a hidden failure.Closing.
On v3.5.3-beta.1 (8650c58),
/api/healthchecks the live writer's current error and recent rejected ticks, but does not expose a failed hourly archive/retention job. A later successful commit also clearslast_error, leaving no counter or timestamp for recovered commit failures. A ready learned model is likewise not proof that observation and model persistence currently work.Expose the current maintenance phase/result, last success, last failure and failure counts under history storage. Keep recovered failures as diagnostic history while clearing the current degraded state after successful recovery. Make archive failures affect overall health. Provide explicit forecast learning health for the simple UI in #1278; do not derive Healthy from model readiness alone or invent learning start dates.
Tests must cover a failed maintenance run followed by a successful one, a recovered live commit, waiting for fresh measurements, pending model/observation persistence and queue overflow. Related: #1275, #1276, #1277 and #1149.