fix: `notifications` Config Parsed but Never Used — No Notifications Are Ever Sent

[pvandervelde]

Repository: pvandervelde/release_regent
Affects: All event processing — error reporting, release completion
Date: 2026-05-18

---

Summary

The entire [notifications] config section is fully defined in the config schema,
correctly parsed and merged by the config provider, and documented in the configuration
reference. However, no code in the core processing path ever reads notifications.* or
sends any notification. The feature is completely unimplemented at the processing layer.

---

Configuration (correct — not the cause)

[notifications]
enabled = true
strategy = "github_issue"

[notifications.github_issue]
labels = ["release-regent", "bug"]
assignees = ["on-call-team"]

All of these keys map to NotificationConfig (and its sub-structs GitHubIssueConfig,
WebhookConfig, SlackConfig) in crates/core/src/config.rs. They are correctly
parsed and stored. The configuration is not the problem.

---

Root Cause

No notification-sending code exists in lib.rs or any handler

A search for notifications in crates/core/src/lib.rs returns zero matches outside of
struct definitions. The five event-processing functions — handle_release_pr_merged,
handle_pr_comment, handle_pull_request_merged, handle_pull_request_activity, and
refresh_open_feature_pr_comments — handle errors by returning CoreError to the
caller or logging a warning, but never consult repo_config.notifications to decide
whether and how to notify anyone.

The config is present but has no consumer

NotificationConfig is:

• Defined in crates/core/src/config.rs with three delivery strategies (GitHub Issue,
  Webhook, Slack)
• Merged by crates/config_provider/src/github_provider.rs (non-lockable policy path)
• Documented in the configuration reference (docs/specs/operations/configuration.md)

But it is never read in any event-processing path.

---

Impact

• When release-regent encounters a processing error (e.g. a failed GitHub API call,
  a version calculation failure), no notification is sent. Operators have no automated
  signal that a release was not completed.
• Users who configure notifications.enabled = false expecting to suppress GitHub
  issue creation get the same behaviour as users with enabled = true — no issues are
  created in either case.
• The three delivery strategies (GitHub Issue, Webhook, Slack) are entirely unbuilt.

---

What Needs to Be Built

This is a substantial feature, not a simple wiring fix. The following sub-systems need
to be designed and implemented:

1. Notification dispatcher — A component that accepts a NotificationConfig and an
   event (error, release created, etc.) and routes it to the correct delivery strategy.
2. GitHub Issue strategy — On error, open (or update) a GitHub issue in the target
   repository with configurable labels and assignees.
3. Webhook strategy — POST a JSON payload to notifications.webhook.url with
   optional custom headers.
4. Slack strategy — POST a formatted message to notifications.slack.webhook_url,
   optionally targeting a specific channel.
5. Dispatch points in lib.rs — Call the dispatcher at the appropriate points in
   each handler (at minimum: on unrecoverable error, on successful release creation).
6. Idempotency — For the GitHub Issue strategy, avoid creating duplicate issues for
   the same error (e.g. check for an existing open issue with matching labels before
   creating a new one).

Minimum Viable Slice

The GitHub Issue strategy is the most useful for operators and requires no external
integrations beyond the GitHub API already in use. Implementing that strategy alone, for
error events only, would close the most important part of this gap.

---

Files Likely to Change

• crates/core/src/lib.rs — add notification dispatch calls in event handlers
• crates/core/src/ — new module for the notification dispatcher
• crates/core/src/traits/github_operations.rs — may need create_issue / list_issues
  operations if not already present
• Tests — add tests for each notification strategy and for the suppression path
  (enabled = false)