Lightning proximity alerts (#87 Phase B) #120

Merged

claude-bot merged 1 commit from feat/lightning-proximity into main

2026-07-22 02:23:52 +00:00

claude-bot commented

2026-07-22 02:17:38 +00:00

Contributor

Second half of #87 — completes it. Opt-in per location; default (no radius set) is a no-op, zero behavior change.

Migration 0029: Location.lightning_alert_radius_mi (null = off) + lightning_last_alerted_at (cooldown), ChannelLocationSub.notify_lightning.
services/lightning_alerts.py — poll_lightning() reuses the Phase A fetch_lightning per location (shared cache), keeps clusters within a haversine_miles radius and newer than LIGHTNING_ALERT_MAX_AGE_MINUTES, respects a per-location cooldown (LIGHTNING_ALERT_COOLDOWN_MINUTES) and location snooze, and dispatches a synthetic "Lightning Nearby" alert through the existing per-notifier send path (same pattern as the outbreak digest — no new per-notifier code). Cooldown is stamped only after a real dispatch, so a quiet-hours-only suppression retries next cycle. Fail-soft per location.
Severity = advisory → lightning respects quiet hours (suppressible at night); it's a heads-up, not a life-safety warning.
Scheduler job every LIGHTNING_POLL_INTERVAL_MINUTES (no-op when the feed isn't configured).
UI: per-location "Lightning alert radius (mi)" + per-subscription "Lightning proximity alerts" toggle, wired through schemas, create/partial endpoints, and config import/export.

Testing (dev server)

ruff clean; 10 proximity tests (radius/age/cooldown/quiet-hours/opt-in boundaries + haversine); bulk suite 775 passed; migration 0029 applied on a restored copy of the real dev DB (all three columns present).

Closes #87

🤖 Generated with Claude Code

Second half of #87 — completes it. Opt-in per location; default (no radius set) is a **no-op**, zero behavior change. - **Migration 0029**: `Location.lightning_alert_radius_mi` (null = off) + `lightning_last_alerted_at` (cooldown), `ChannelLocationSub.notify_lightning`. - **`services/lightning_alerts.py`** — `poll_lightning()` reuses the Phase A `fetch_lightning` per location (shared cache), keeps clusters within a `haversine_miles` radius **and** newer than `LIGHTNING_ALERT_MAX_AGE_MINUTES`, respects a per-location cooldown (`LIGHTNING_ALERT_COOLDOWN_MINUTES`) and location snooze, and dispatches a synthetic **"Lightning Nearby"** alert through the existing per-notifier send path (same pattern as the outbreak digest — no new per-notifier code). Cooldown is stamped **only after a real dispatch**, so a quiet-hours-only suppression retries next cycle. Fail-soft per location. - **Severity = advisory** → lightning **respects quiet hours** (suppressible at night); it's a heads-up, not a life-safety warning. - Scheduler job every `LIGHTNING_POLL_INTERVAL_MINUTES` (no-op when the feed isn't configured). - **UI**: per-location "Lightning alert radius (mi)" + per-subscription "Lightning proximity alerts" toggle, wired through schemas, create/partial endpoints, and config import/export. ## Testing (dev server) ruff clean; 10 proximity tests (radius/age/cooldown/quiet-hours/opt-in boundaries + haversine); bulk suite **775 passed**; migration 0029 applied on a **restored copy of the real dev DB** (all three columns present). Closes #87 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit

2026-07-22 02:17:38 +00:00

Add lightning proximity alerts (#87 Phase B)

CI / test (pull_request) Successful in 4m51s

Details

524a47a119

Opt-in per location: set a lightning alert radius on a location and a poll job
notifies its lightning-subscribed channels when recent ENTLN clusters fall within
that radius. Default (no radius set) is a no-op — zero behavior change.

- Migration 0029: Location.lightning_alert_radius_mi (null=off) +
  lightning_last_alerted_at (cooldown), ChannelLocationSub.notify_lightning.
- app/services/lightning_alerts.py: poll_lightning() reuses fetch_lightning per
  location (shared cache), keeps clusters within haversine_miles radius AND newer
  than LIGHTNING_ALERT_MAX_AGE_MINUTES, respects a per-location cooldown
  (LIGHTNING_ALERT_COOLDOWN_MINUTES) and location snooze, and dispatches a synthetic
  "Lightning Nearby" advisory-severity alert through the existing per-notifier send
  path (no new per-notifier code). Cooldown is stamped only after a real dispatch,
  so a quiet-hours-only suppression retries next cycle. Fail-soft per location.
- Advisory severity → lightning respects quiet hours (suppressible at night); it is
  a heads-up, not a life-safety warning.
- Scheduler job every LIGHTNING_POLL_INTERVAL_MINUTES (no-op when the feed is
  unconfigured). Config vars added.
- UI: per-location radius input + per-subscription "Lightning proximity alerts"
  toggle, wired through schemas, create/partial endpoints, and config import/export.

Verified on the dev server: ruff clean, 10 proximity tests, bulk 775 passed;
migration 0029 applied on a real-DB copy.

Closes #87

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

claude-bot merged commit 61d4ae7101 into main

2026-07-22 02:23:52 +00:00

claude-bot deleted branch feat/lightning-proximity

2026-07-22 02:23:53 +00:00

claude-bot referenced this pull request from a commit

2026-07-22 02:23:54 +00:00

Merge pull request 'Lightning proximity alerts (#87 Phase B)' (#120) from feat/lightning-proximity into main

claude-bot referenced this pull request

2026-07-22 02:24:19 +00:00

Lightning: radar overlay + proximity-alert follow-on #87

claude-bot referenced this pull request

2026-07-22 02:24:51 +00:00