mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-10-26 05:29:45 +00:00
rcourtman
dc93d0adea
When adaptive polling is enabled (ADAPTIVE_POLLING_ENABLED or system.json; off by default, no UI), the scheduler picks PVE, PBS and PMG intervals itself and never reads the per-platform ones. A healthy instance's staleness score is near zero after every success, so its cadence stretches toward AdaptivePollingMaxInterval (5 minutes by default). Resource freshness was still derived from the per-platform intervals, with floors of 60s for Proxmox and 120s for PBS and PMG, so healthy rows read stale for much of every cycle. A live stack with a fake PMG polled 3.5 to 4.3 minutes apart and the row sat degraded with telemetry_stale from two minutes after each poll until the next one. The PVE node offline grace and the node temperature carry window derive from the same cadence and lapsed between polls too. Monitor.resourcePollIntervals now judges all three sources by the scheduler's own maximum interval, which bounds every interval it selects. ResourceStaleThresholdsForConfig reads the same normalized bounds through a normalizedSchedulerConfig shared with NewAdaptiveScheduler, so callers without a monitor agree with the one that has it. The same live stack stayed online for 14 minutes. Fixed-cadence behaviour is unchanged. Per-instance planned intervals were not used: they are jittered and shrink as a poll runs late, so a per-source threshold built on them would flap. The contract note this replaces said freshness keeps deriving from the per-platform intervals; the user doc now says what adaptive polling does to freshness and offline detection. The cost is a longer node hold in adaptive mode (10 minutes with the defaults). A valid /cluster/status report that a member is offline still applies immediately.