Goal
Verify that notification behavior has one clear orchestration layer after the central notification-event work.
The current implementation has a central event dispatcher, but low-level mail, Unraid notify, ntfy, weekly report, and test endpoints still exist in different modules. Some of this is intentional transport separation; this issue is to audit and remove only true duplication.
Current paths found
runtime/lib/notification_events.py
- central event dispatch for backup, restore-test, and overdue events
runtime/lib/notifications.py
- low-level Unraid, email, backup-log email, and ntfy transport helpers
runtime/lib/backup_job.py
- sends backup events through the central event layer
runtime/scripts/borg_restore_test.py
- sends restore-test events through the central event layer
api/notification_reminder_api.py
- computes overdue diagnostics and reminder state
api/ntfy_api.py and api/smtp_api.py
- direct test/config endpoints
api/report_mail_api.py
- weekly report mail flow remains separate
runtime/lib/vm_manager.py
- still calls low-level Unraid notify directly for VM control messages
Risk
If event sends bypass the central layer unintentionally, event selection, reminder throttling, templates, language, and secret masking can diverge between channels.
Scope
- Define which direct transport calls are intentional and document them.
- Ensure backup, restore-test, overdue, and runtime failure events use the central event layer where appropriate.
- Keep explicit test endpoints as direct transport tests.
- Decide whether weekly reports remain a separate report channel or become a notification event category later.
- Ensure secrets never reach logs or user-visible error output.
Acceptance criteria
- A documented notification event matrix exists for current channels.
- Normal operational events route through the central event dispatcher or have a documented reason not to.
- Test endpoints remain available and do not affect reminder state.
- Tests cover event selection, disabled channels, transport failures, and secret masking.
Goal
Verify that notification behavior has one clear orchestration layer after the central notification-event work.
The current implementation has a central event dispatcher, but low-level mail, Unraid notify, ntfy, weekly report, and test endpoints still exist in different modules. Some of this is intentional transport separation; this issue is to audit and remove only true duplication.
Current paths found
runtime/lib/notification_events.pyruntime/lib/notifications.pyruntime/lib/backup_job.pyruntime/scripts/borg_restore_test.pyapi/notification_reminder_api.pyapi/ntfy_api.pyandapi/smtp_api.pyapi/report_mail_api.pyruntime/lib/vm_manager.pyRisk
If event sends bypass the central layer unintentionally, event selection, reminder throttling, templates, language, and secret masking can diverge between channels.
Scope
Acceptance criteria