Problem
src/review/alerts.ts (recordAnomalyAlertDelivery path, ~line 233) INSERTs into notification_deliveries with the column set (id, project, target_id, notification_key, status) — but the table's actual schema (migration 0031_notification_subscriptions.sql) has (id, pull_number, dedup_key, channel, recipient_login, event_type, repo_full_name, title, body, deeplink, actor_login, status, created_at, delivered_at, read_at). None of project, target_id, notification_key exist.
Every anomaly-alert delivery attempt therefore fails at write time. Live selfhost logs, 2026-07-26 15:03Z:
{"level":"error","event":"anomaly_alert_wire_error","message":"error: column \"project\" of relation \"notification_deliveries\" does not exist"}
The ops-anomaly detector itself works (it produced real findings in the same log lines — e.g. a slop-score discrimination anomaly) but the alert wire drops them, so nobody is notified. The insert appears to have been written against a planned/imagined schema (or a different table) and has never worked against the real one.
Fix
Either point the anomaly-alert wire at its own correctly-migrated table, or map its fields onto notification_deliveries' real columns (dedup_key looks like the intended home of notification_key; repo_full_name for project). Add a regression test that executes the INSERT against the real schema — this class of drift (query written against a nonexistent column set) should fail in CI, not in production.
Acceptance
- Anomaly alerts write a delivery row and reach the configured channel; the
anomaly_alert_wire_error log line no longer occurs.
- A schema-conformance test covers the statement.
Problem
src/review/alerts.ts(recordAnomalyAlertDeliverypath, ~line 233) INSERTs intonotification_deliverieswith the column set(id, project, target_id, notification_key, status)— but the table's actual schema (migration0031_notification_subscriptions.sql) has(id, pull_number, dedup_key, channel, recipient_login, event_type, repo_full_name, title, body, deeplink, actor_login, status, created_at, delivered_at, read_at). None ofproject,target_id,notification_keyexist.Every anomaly-alert delivery attempt therefore fails at write time. Live selfhost logs, 2026-07-26 15:03Z:
The ops-anomaly detector itself works (it produced real findings in the same log lines — e.g. a slop-score discrimination anomaly) but the alert wire drops them, so nobody is notified. The insert appears to have been written against a planned/imagined schema (or a different table) and has never worked against the real one.
Fix
Either point the anomaly-alert wire at its own correctly-migrated table, or map its fields onto
notification_deliveries' real columns (dedup_keylooks like the intended home ofnotification_key;repo_full_nameforproject). Add a regression test that executes the INSERT against the real schema — this class of drift (query written against a nonexistent column set) should fail in CI, not in production.Acceptance
anomaly_alert_wire_errorlog line no longer occurs.