Alarms: stamp 'last checked' on completion to avoid false positives by bjorkert · Pull Request #471 · loopandlearn/LoopFollow

Summary

This PR fixes a race where Missed Reading and Not Looping alarms could fire while BG/Loop checks were still running.
We now mark the “last checked” timestamps after the data fetch has either succeeded (and been processed) or finally failed. That way, the alarm logic only validates once the attempt is actually finished.

What changed

  • BG

    • Added Storage.shared.lastBGChecked.
    • Set on success at the end of viewUpdateNSBG(...) (after observables/UI updates).
    • Set on final failure when NS is disabled or NS fetch fails and there’s no Dex fallback; also when a processor receives empty data.
    • MissedReadingCondition now requires a recent lastBGChecked (≤ 6 min) before evaluating staleness.
  • Loop

    • Moved Storage.shared.lastLoopingChecked from start of webLoadNSDeviceStatus() to the end of success handling (after updateDeviceStatusDisplay) and to the error path (final failure).
    • This mirrors the BG behavior to prevent “not looping” alarms from firing during in-flight device status checks.

Why

Previously, we stamped the “checked” moment at the start of network calls. If the alarm evaluator ran in parallel—while lastLoopTime or BG entries were still old—we could alarm prematurely.