Found while implementing #132 (whose file surface is content/docs/configure/notifications.mdx only, so this was recorded rather than fixed). Filed unassigned.
content/docs/operate/audit-logs.mdx:100-104:
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 when a user reports a missing alert.
The subscription half of that sentence is the same claim #132 corrects on the Notifications page: the subscription→recipient expansion is not wired, so a subscription row cannot filter anything out. This one is worse than a description error because it is diagnostic advice — it sends an admin chasing a missing alert to the Setup "Notification Subscriptions" grid, where nothing they change can affect delivery.
Measured on objectstack origin/main @ 2866d5f97e (the same measurement #132 rests on, re-run):
AudienceSpec (packages/services/service-messaging/src/messaging-service.ts:51) has no 'subscribers' member; EmitInput.audience is required.RecipientResolver.resolveOne() (recipient-resolver.ts:113-146) branches on user: / role: / team: / owner_of: / email / bare id — no branch reads sys_notification_subscription.- Outside its own declaration, the Setup nav entry and tests, nothing references
sys_notification_subscription.
- The object's own header carries the upstream
⚠️ [#9807] … NOT WIRED in this repo annotation.
What is true for that sentence: the preference half. MessagingService.emit() calls PreferenceResolver.filter() on the resolved recipients (messaging-service.ts:707) and logs suppressed for all recipients by preference when it empties. So the honest advice is: an event with no inbox message means the producer's audience did not resolve to that user, or their preference muted the topic on that channel.
Scoping, kept the same as the framework's annotation and as #132's wording: this is a statement about the platform notification pipeline (objectstack measured; objectui measured — zero runtime readers, counter-checked against sys_inbox_message; the cloud repo was not measured, recorded as a declared narrowing rather than guessed).
Suggested fix: drop "a subscription or" from that sentence and let it name the two real causes (audience did not include the user; preference muted it). One-line edit, but on a page outside #132's surface and inside no other card's completion scope, hence a separate issue.
Related: #132, objectstack-ai/objectstack#9807 (ruling), objectstack-ai/objectstack#10027 (the landed annotation).
Found while implementing #132 (whose file surface is
content/docs/configure/notifications.mdxonly, so this was recorded rather than fixed). Filed unassigned.content/docs/operate/audit-logs.mdx:100-104:The subscription half of that sentence is the same claim #132 corrects on the Notifications page: the subscription→recipient expansion is not wired, so a subscription row cannot filter anything out. This one is worse than a description error because it is diagnostic advice — it sends an admin chasing a missing alert to the Setup "Notification Subscriptions" grid, where nothing they change can affect delivery.
Measured on
objectstackorigin/main@2866d5f97e(the same measurement #132 rests on, re-run):AudienceSpec(packages/services/service-messaging/src/messaging-service.ts:51) has no'subscribers'member;EmitInput.audienceis required.RecipientResolver.resolveOne()(recipient-resolver.ts:113-146) branches onuser:/role:/team:/owner_of:/ email / bare id — no branch readssys_notification_subscription.sys_notification_subscription.⚠️ [#9807] … NOT WIRED in this repoannotation.What is true for that sentence: the preference half.
MessagingService.emit()callsPreferenceResolver.filter()on the resolved recipients (messaging-service.ts:707) and logssuppressed for all recipients by preferencewhen it empties. So the honest advice is: an event with no inbox message means the producer's audience did not resolve to that user, or their preference muted the topic on that channel.Scoping, kept the same as the framework's annotation and as #132's wording: this is a statement about the platform notification pipeline (
objectstackmeasured;objectuimeasured — zero runtime readers, counter-checked againstsys_inbox_message; thecloudrepo was not measured, recorded as a declared narrowing rather than guessed).Suggested fix: drop "a subscription or" from that sentence and let it name the two real causes (audience did not include the user; preference muted it). One-line edit, but on a page outside #132's surface and inside no other card's completion scope, hence a separate issue.
Related: #132, objectstack-ai/objectstack#9807 (ruling), objectstack-ai/objectstack#10027 (the landed annotation).