Skip to content

New alert architecture - #284

Draft
hickey wants to merge 2 commits into
agessaman:devfrom
hickey:feat/new-alert-architecture
Draft

hickey wants to merge 2 commits into
agessaman:devfrom
hickey:feat/new-alert-architecture

Conversation

@hickey

@hickey hickey commented Sep 14, 2026

Copy link
Copy Markdown

What this changes

This changes the alert command from being tied to the PulsePoint API to a query command that can query one or more backend alert services.

Why

PulsePoint is not used everywhere and rather than create commands for every alert service that a user may implement it makes more sense to allow the alert command to query the available backend services.

Testing

This is still being tested and verified. I have no why to test the PulsePoint API directly. I don't have the PulsePoint agency ID for King county, but if you can post it to this PR I would be happy to also test the PulsePoint integration also.

Checklist

  • Branched from dev and targeting dev
  • make test passes
  • make lint passes (ruff + mypy)
  • Frontend lint passes if templates changed (npm run lint:frontend)
  • Tests added or updated for behavior changes
  • CHANGELOG.md updated under ## [Unreleased] if user-visible
  • Config changes are reflected in config.ini.example (and the minimal/quickstart
    templates where relevant) — CI validates these with validate_config.py --strict
  • New docs pages are added to nav: in mkdocs.yml
  • Any new command justifies its airtime and defaults conservatively

Decouple the alert command from PulsePoint and turn it into a thin
orchestrator over pluggable "alert services". Each service encapsulates
one incident source and supports two independent modes: query mode (via
the alert command) and polling mode (auto-posting new incidents to
channels).

- Add BaseAlertService (extends BaseServicePlugin) providing the polling
  loop, channel posting, duplicate tracking (in-memory + bot_metadata),
  label handling, and config plumbing. Subclasses implement parse_query,
  query_alerts, get_capabilities, and optionally fetch_new_incidents.
- Add PulsePointAlertService: all PulsePoint logic (AES decryption, API
  fetch, query parsing, ranking, compact formatting) migrated out of the
  command; supports query and polling modes.
- Rewrite AlertCommand as an orchestrator: discovers connected services
  from [Alert_Command] services, queries all connected services (or only
  the service polling the current channel), distributes the incident
  budget evenly with redistribution of unused shares, and sends
  [LABEL]:-prefixed messages.
- Exclude base_alert_service from service discovery.
- Register [PulsePoint_Alert_Service] in config schema/validation and
  allow agency.* keys there.
- Update config.ini.example: new [PulsePoint_Alert_Service] section;
  [Alert_Command] gains `services` and `max_incidents_total`.
- Add docs/alert-service.md (architecture, service-authoring guide,
  query-parameter mapping, config reference, troubleshooting) and link
  it from index, mkdocs nav, and service-plugins overview.
- Add tests/test_alert_service.py (32 tests) and retarget the alert
  parse_query characterization tests at the service.

Backward compatible: `services` defaults to pulsepoint, the legacy `all`
suffix is now implicit, and agency.* / alert_enabled still work.

Signed-off-by: Gerard Hickey <hickey@kinetic-compute.com>
Signed-off-by: Gerard Hickey <hickey@kinetic-compute.com>
@hickey
hickey marked this pull request as draft September 14, 2026 18:14
@hickey

hickey commented Sep 14, 2026

Copy link
Copy Markdown
Author

I wonder if other services should use the same architecture.. (e.g. Earthquake_Service and Weather_Service)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant