iris_scheduler_last_success_timestamp_seconds is off by the UTC offset when TZ isn't UTC #176
Labels
No labels
area/ai
area/backend
area/frontend
area/infra
area/scheduler
area/wled
good-first-issue
priority/high
priority/low
priority/medium
security
type/bug
type/chore
type/ci-cd
type/docs
type/feature
type/qa
v1.0.0
v1.1.0
v1.2.0
v2.0.0
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
rbrooks/Iris-WLED#176
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Bug
metrics._schedule_metricscalls.timestamp()onschedule_log.triggered_at, which is stored as naive UTC. Python interprets a naive datetime's.timestamp()as local time. Since #147,TZactually reaches the container, so withTZ=America/Chicagothe gauge reads 5 or 6 hours off.This is the metric the recommended alert is built on (
IrisLightsDidNotComeOn,docs/setup.md§8:time() - iris_scheduler_last_success_timestamp_seconds{job="on_job"} > 129600). An offset in the wrong direction makes that alert fire hours early or late.test_metrics.pycurrently asserts the buggy behaviour. Found while building #148, whose new gauge uses UTC correctly.Fix
Use
triggered_at.replace(tzinfo=UTC).timestamp()(or store tz-aware values). Updatetest_metrics.pyto run under a non-UTCTZand assert the true epoch. Check the other.timestamp()calls on naive DB datetimes for the same mistake.