From 4515729be819685fd0fe635536a5bec6787c915a Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 29 Aug 2026 13:52:06 +0000 Subject: [PATCH] docs(operate): correct audit-logs missing-notification diagnostic The subscription->recipient expansion is not wired (AudienceSpec has no 'subscribers' member, EmitInput.audience is required, and no RecipientResolver branch reads sys_notification_subscription), so a subscription row cannot filter a delivery out. Only the preference filter (PreferenceResolver.filter() in emit()) is real. Drop "a subscription or" and name the two real causes: the audience did not resolve to the user, or their preference muted the topic on that channel. Fixes #146 --- content/docs/operate/audit-logs.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/docs/operate/audit-logs.mdx b/content/docs/operate/audit-logs.mdx index b696ab5..59597a3 100644 --- a/content/docs/operate/audit-logs.mdx +++ b/content/docs/operate/audit-logs.mdx @@ -99,10 +99,10 @@ and `Created At`. The `dedup_key` collapses duplicate emits, and `payload` carries the raw event context that templates render from. Because this log sits *upstream* of routing, -a row here with no matching inbox message usually means a subscription or -preference filtered the event out — check -[Notifications](/docs/configure/notifications) when a user reports a missing -alert. +a row here with no matching inbox message usually means the audience did not +resolve to that user, or their preference muted the topic on that channel — +check [Notifications](/docs/configure/notifications) when a user reports a +missing alert. Downstream, each event is materialized into per-user inbox messages (`sys_inbox_message`) — the recipient's view lives under