>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3608699. --> Reported by: [marcus_johansson](https://www.drupal.org/user/385947) Related to !25 >>> <h3>Problem/Motivation</h3> <p>Alerting is currently hard-wired to email. <code>AlertService::checkAndAlert()</code> both decides <em>whether</em> an alert should fire (the threshold-crossing logic) and <em>how</em> it is delivered (it calls <code>MailManagerInterface::mail()</code> directly and loops over <code>alerts.emails</code>). The two responsibilities are entangled in one class.</p> <p>This has real limitations:</p> <ul> <li>Teams that manage AI budgets in Slack, Microsoft Teams, PagerDuty, or a custom monitoring system cannot receive alerts without patching the module. Webhook/Slack delivery is on the roadmap but has no code - it only exists as an example in <code>ai_metering.api.php</code>.</li> <li>Adding a new delivery mechanism means editing <code>AlertService</code> itself, so every channel a site needs has to live in this module rather than in the site's or a contrib module's own code.</li> <li>The delivery logic is not independently testable - a channel cannot be unit-tested without exercising the threshold math around it.</li> </ul> <p>Delivery is a good fit for Drupal's plugin system: the service should own the decision, and each channel should own its own delivery.</p> <h3>Proposed Resolution</h3> <p>Split alert delivery into a plugin type so <code>AlertService</code> is reduced to detection only.</p> <ul> <li>Define an <code>AlertChannel</code> plugin type - an <code>AlertChannelInterface</code>, an <code>AlertChannelBase</code>, an attribute/annotation, and a plugin manager (<code>ai_metering.alert_channel</code>). Plugins are discovered from <code>src/Plugin/AlertChannel/</code>.</li> <li>Introduce a small value object (for example <code>AlertEvent</code>) carrying the alert payload that <code>checkAndAlert()</code> already assembles: <code>uid</code>, <code>username</code>, <code>threshold</code>, <code>pct_used</code>, <code>tokens_used</code>, <code>budget</code>. <code>AlertChannelInterface::send(AlertEvent $event): void</code> receives it.</li> <li>Refactor <code>AlertService</code> to keep only the once-per-threshold-crossing detection logic. After a crossing is detected it builds the <code>AlertEvent</code> and dispatches it to every enabled channel via the plugin manager, instead of calling <code>MailManagerInterface</code> itself.</li> <li>Move the existing email behaviour into an <code>email</code> <code>AlertChannel</code> plugin. It wraps the current <code>MailManagerInterface</code> call, the <code>alerts.emails</code> recipient loop, the per-address <code>FILTER_VALIDATE_EMAIL</code> check, and the failure logging. Behaviour is preserved so existing sites see no change.</li> <li>Add a <code>webhook</code> <code>AlertChannel</code> plugin that POSTs a JSON body built from the <code>AlertEvent</code> to a configured endpoint via the <code>http_client</code> service, with a Slack-compatible payload shape (a <code>text</code> summary plus the structured fields) so it works with Slack and Teams incoming webhooks out of the box. Failures are logged and never interrupt the metering request.</li> <li>Extend <code>ai_metering.settings</code> and its schema with per-channel enable flags and channel config - for the webhook plugin at minimum a <code>url</code>, an optional secret/header, and a timeout. The settings form gains a section per channel.</li> <li>Tests: a unit test per channel (email delivery, webhook payload shape and enabled/disabled behaviour) plus an <code>AlertService</code> test asserting it dispatches to enabled channels exactly once per crossing and does no delivery itself.</li> </ul> <p>Result: <code>AlertService</code> owns <em>when</em>, plugins own <em>how</em>, and sites can add channels without touching this module.</p> <h3>AI Assistance</h3> <p>Yes, AI was used to explore the issue.</p>