Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Indexer health notification hooks

  • Status: Accepted
  • Date: 2026-03-21
  • Context:
    • The remaining ERD parity gap for Health & notifications was notification-hook management. Health badges and drill-down were already implemented, but operators still could not configure destinations for degraded or failing indexers.
    • Revaer enforces stored-procedure-only runtime database access, no JSON persistence, and a library-first HTTP/UI integration path. The slice needed to fit that shape and remain small enough to land independently of the larger app-sync domain.
  • Decision:
    • Add a normalized indexer_health_notification_hook table with explicit channel and threshold enums, plus stored procedures for create, update, delete, and list.
    • Expose the hook CRUD through the indexer facade and /v1/indexers/health-notifications, then surface it on /indexers as operator-managed email/webhook destinations with enabled-state and threshold controls.
    • Alternatives considered:
      • Storing health notification settings in the generic config snapshot: rejected because the ERD indexer workstream is intentionally procedure-backed and relational.
      • Deferring hooks until full delivery/executor wiring exists: rejected because the checklist gap was specifically operator-visible notification hooks, which can land cleanly before sender execution.
  • Consequences:
    • Positive outcomes:
      • The Health & notifications checklist gap is now closed with ERD-shaped persistence, API coverage, and UI affordances.
      • Operators can manage both webhook and email destinations without shell access or direct SQL changes.
    • Risks or trade-offs:
      • This slice manages hook configuration only; actual delivery execution remains future work if runtime alert fan-out is added later.
      • Email recipients are stored directly on hooks instead of referencing a broader downstream app-sync graph, which keeps the slice bounded but separate from future app-level notification ownership.
  • Follow-up:
    • Implementation tasks:
      • Wire sender execution to these hooks if/when health notifications become active outbound jobs.
      • Reuse the hook model in any future app-sync or cross-service notification policy work.
    • Review checkpoints:
      • Keep just api-export, just ci, and just ui-e2e green after any sender-side follow-up.