Dashboard freshness warning stuck on, reading "last updated 0 min ago", after the last location in a state is removed #204

Closed
opened 2026-10-13 17:10:57 +00:00 by claude-bot · 2 comments
Collaborator

Reported by @rbrooks on dev (2.0.0-rc5), 2026-10-13. The dashboard shows:

⚠ Data freshness warning: NWS Alerts data last updated 0 min ago. Some information on this page may be out of date.

Not introduced by rc5. Two defects combine.

1. Freshness rows for a state outlive its locations

NWS alert freshness is tracked per state (product_freshness.key = nws_alerts:<STATE>), and a row is only ever refreshed by polling that state. poll_alerts_job polls the states of enabled, ready locations. When the last location in a state is deleted or disabled, its row is never touched again and never removed, so it reads as stale forever.

Dev has nws_alerts:TX from a location that no longer exists. At rc5 startup the watchdog logged:

ADMIN ALERT — Product stale: NWS active alerts for TX: last success 212840 min ago (threshold 30 min)

That is about 148 days. It holds both the dashboard banner and the stale-product admin alert on permanently. Same class of bug as #161 (dead SPC rows pinning the banner), reached by a different route.

2. The banner reports the wrong feed's age

dashboard_freshness_summary decides health from any unhealthy row in the category, but computes the age it prints from max(last_success_at) across the category, i.e. the freshest row. One stale state beside a healthy one therefore renders a staleness warning that says the data is 0 minutes old.

Fix

  • Prune nws_alerts:* freshness rows for states no location monitors, from poll_alerts_job, fail-soft so housekeeping can never cost an alert poll.
  • Make the banner report the age of the degraded feed.

Production is not currently affected in a visible way (it polls one state and has no orphan), but would be the first time a location in a second state is removed.

Also requested in the same message

Explorer calendar: the click target for a day is only the day number; make the whole cell clickable. Handled in the same PR.

Reported by @rbrooks on dev (`2.0.0-rc5`), 2026-10-13. The dashboard shows: > ⚠ **Data freshness warning:** NWS Alerts data last updated 0 min ago. Some information on this page may be out of date. Not introduced by rc5. Two defects combine. ## 1. Freshness rows for a state outlive its locations NWS alert freshness is tracked per state (`product_freshness.key = nws_alerts:<STATE>`), and a row is only ever refreshed by polling that state. `poll_alerts_job` polls the states of enabled, ready locations. When the last location in a state is deleted or disabled, its row is never touched again and never removed, so it reads as stale forever. Dev has `nws_alerts:TX` from a location that no longer exists. At rc5 startup the watchdog logged: ``` ADMIN ALERT — Product stale: NWS active alerts for TX: last success 212840 min ago (threshold 30 min) ``` That is about 148 days. It holds both the dashboard banner and the stale-product admin alert on permanently. Same class of bug as #161 (dead SPC rows pinning the banner), reached by a different route. ## 2. The banner reports the wrong feed's age `dashboard_freshness_summary` decides health from **any** unhealthy row in the category, but computes the age it prints from `max(last_success_at)` across the category, i.e. the freshest row. One stale state beside a healthy one therefore renders a staleness warning that says the data is 0 minutes old. ## Fix - [ ] Prune `nws_alerts:*` freshness rows for states no location monitors, from `poll_alerts_job`, fail-soft so housekeeping can never cost an alert poll. - [ ] Make the banner report the age of the degraded feed. Production is not currently affected in a visible way (it polls one state and has no orphan), but would be the first time a location in a second state is removed. ## Also requested in the same message Explorer calendar: the click target for a day is only the day number; make the whole cell clickable. Handled in the same PR.
Author
Collaborator

Merged via #205 (06880c1). CI run 248 green in 5m58s, both test tiers.

Leaving this open until it is confirmed on dev, which needs the next release candidate (rc5 does not contain it). To confirm there:

  • The banner is gone from the dashboard, and the log shows Pruned 1 NWS alert freshness row(s) for states no longer monitored on the first poll.
  • The startup admin alert for TX no longer fires.
  • Clicking anywhere in an Explorer day cell opens that day. This part has not been exercised in a browser at all yet.
Merged via #205 (`06880c1`). CI run 248 green in 5m58s, both test tiers. Leaving this open until it is confirmed on dev, which needs the next release candidate (rc5 does not contain it). To confirm there: - The banner is gone from the dashboard, and the log shows `Pruned 1 NWS alert freshness row(s) for states no longer monitored` on the first poll. - The startup admin alert for TX no longer fires. - Clicking anywhere in an Explorer day cell opens that day. This part has not been exercised in a browser at all yet.
Author
Collaborator

Confirmed on dev (2.0.0-rc6) by @rbrooks, 2026-10-13: the freshness banner is gone, the Explorer calendar's day cells are clickable across the whole box, and the Add Location dialog opens blank on a second add (PR #207, shipped alongside).

On the host: the first alert poll pruned nws_alerts:TX, the remaining freshness rows are the five monitored states, and the TX admin alert no longer fires at startup. Closing.

Confirmed on dev (`2.0.0-rc6`) by @rbrooks, 2026-10-13: the freshness banner is gone, the Explorer calendar's day cells are clickable across the whole box, and the Add Location dialog opens blank on a second add (PR #207, shipped alongside). On the host: the first alert poll pruned `nws_alerts:TX`, the remaining freshness rows are the five monitored states, and the TX admin alert no longer fires at startup. Closing.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rbrooks/WeatherBot#204
No description provided.