Correct sdp-expectation-notifications docs from the 2026-08-22 egress and destination verification (v1.12.2)

CHANGELOG.md

@@ -7,13 +7,27 @@ and this project adheres to [Semantic Versioning](https://semver.org/).
 
 ## [Unreleased]
 
+## [1.12.2] - 2026-08-23
+
+### Changed
+- **Asset `sdp-expectation-notifications` (docs only)**: nine corrections and additions grounded in a live verification session (2026-08-22, serverless SDP, CLI v0.297.2), none changing behavior.
+  - **Destination config corrected; this supersedes the 1.12.1 bullet below.** For a Databricks SQL alert, a Slack destination takes the incoming webhook URL and nothing else, and so does MS Teams. 1.12.1 said Slack also needs an OAuth token and a channel id, and Teams an App ID, Auth Secret, Channel URL, and Tenant ID; those fields are marked `(optional)` on the Add-destination form and scoped by its own section heading to dashboard subscriptions, a different feature. Confirmed on a Slack destination that delivered five messages while its stored config read `url_set: true, oauth_token_set: false, channel_id_set: false`. Fixed in the asset README, the backstop alert resource comment, and the companion skill.
+  - **The hook email claim re-scoped.** There is no Databricks-native email surface inside a hook, but the hook reaches arbitrary HTTPS: the shipped, unmodified code POSTed to two unrelated third-party collectors, HTTP 200. Two limits travel with that claim wherever it appears: the shipped `requests.post` passes no `headers`, so an authenticated API needs the hook edited first, and the result was measured with no egress controls configured, so in a governed workspace the network policy decides. The no-webhook guidance was broadened to match: the test is any endpoint the hook can post to, not a chat integration specifically.
+  - **`generic` channel format is live-tested**: all six fields arrived verbatim, the two counts as JSON numbers. `teams` remains documented and not live-tested.
+  - **`Empty result state: Error` documented where the sweep query invites edits.** An alert deployed from this asset's resource flips to ERROR if its query returns no rows, and ERROR emails on every evaluation; the shipped `COALESCE(SUM(...), 0)` guarantees exactly one row, so keep that property when editing the query.
+  - **Measured numbers replace asserted ones**: 116 ms per webhook POST on success and 3 ms to fail on an unresolvable name (instrumented), a real `WEBHOOK_DELIVERY_FAILED` instance instead of a described shape, and the alert History panel's `Notified destinations` column as the product's own evidence for one notification per state transition.
+  - **New: one violation, three message shapes.** The hook payload carries the dataset, expectation, and exact counts; the backstop email carries the evaluated metric against its threshold plus a five-run history; a Slack destination carries a state-change title and two links and no data. The destination type therefore also decides how much a responder can triage without clicking.
+  - **Workspace admin is required to manage notification destinations**, stated as documented rather than as stress-tested.
+  - **The companion skill gains the CLI delete behavior**: a delete takes effect immediately but `list` is eventually consistent, so verify with `get`, and a redundant delete errors rather than being idempotent. The create quirk it already documents still reproduces on CLI v0.297.2.
+  - **Stale comment fixed** in `event_log_queries.sql`: its `hook_progress` note still claimed enable/disable state only, which 1.12.0 had corrected everywhere else.
+
 ## [1.12.1] - 2026-07-26
 
 ### Changed
 - **Asset `sdp-expectation-notifications` (docs only)**: seven corrections grounded in two live verification sessions (2026-07-26 drop/destination testing and the 2026-07-17/18 hygiene build), none changing behavior.
   - **Drop coverage documented.** The hook filters purely on `failed_records > 0` and never inspects the expectation's action type, so `warn` and `drop` rules notify identically; the README previously framed the pattern as WARN-only. Live 2026-07-26: a `drop` expectation on the same source and tripwire produced the same passed/failed shape as the shipped WARN row (18929/3003 on 21,932 rows), the hook fired with a matching driver-log line, the update reported `COMPLETED` while discarding 13.7% of rows, `dropped_records` (DROP-only) read 3003 vs 0 on WARN, and the backstop's sweep summed both expectations additively (6,006).
   - **Naming corrected.** "Alert v2" and "Alerts v2" replaced with "Databricks SQL alert(s)" throughout the README, in-bundle doc, skill files, and install prompt text, matching current Databricks docs (legacy alerts is the prior version); `alerts-v2` is kept only where it names an actual CLI command.
-  - **Notification destinations clarified.** Destinations serve only Databricks SQL and jobs, not the event hook, and a destination is a wrapper around a webhook, not a substitute for one (Slack needs a webhook URL, OAuth token, and channel id plus Slack app-install rights; Teams needs a webhook URL, App ID, Auth Secret, Channel URL, and Tenant ID plus Microsoft Copilot Studio and Entra ID permissions). Measured live: a destination alongside `user_email` on the same address sends two independent, non-deduplicated notifications.
+  - **Notification destinations clarified.** Destinations serve only Databricks SQL and jobs, not the event hook, and a destination is a wrapper around a webhook, not a substitute for one (Slack needs a webhook URL, OAuth token, and channel id plus Slack app-install rights; Teams needs a webhook URL, App ID, Auth Secret, Channel URL, and Tenant ID plus Microsoft Copilot Studio and Entra ID permissions). Measured live: a destination alongside `user_email` on the same address sends two independent, non-deduplicated notifications. *[The destination-config detail in this bullet was corrected in 1.12.2: for an alert, Slack and Teams destinations take the webhook URL alone, and the extra fields are optional and belong to dashboard subscriptions. The rest of the bullet stands.]*
   - **No-webhook guidance added.** Readers and the companion skill are now steered to deploy the backstop alone when there is no Slack, Teams, or webhook target, since print-only hook output has no advantage over the event log the backstop already sweeps.
   - **Backstop cron tied to pipeline mode.** The shipped daily cron fits a triggered pipeline; guidance now flags that a continuous pipeline (10-seconds-to-a-few-minutes freshness) needs a tighter cron and window, at the cost of more warehouse wake-ups, pointing at the `monitoring-sql-warehouse` asset.
   - **Grace-period claim softened.** "Terminates compute within roughly 20 seconds" overclaimed precision two runs never measured; replaced with the honest bound (compute alive at ~8s in one run, dead before ~23s in another, neither designed to measure the timer) and the actionable rule: keep hook work in single-digit seconds.