Found while implementing objectui#5190 (which removed the sibling source_object/source_id pair from the same interface). Not fixed there — the ruling on that card named the two source fields only, and the correct disposition here is not mechanically pinned. Filed unassigned as an observation.
What is inconsistent
InboxNotification (packages/app-shell/src/layout/inboxGrouping.ts) declares:
actor_name?: string|null;
On the inbox path that field is dead at both ends:
- No producer fills it.
mergeInboxRows in packages/app-shell/src/hooks/sharedUserFeeds.ts is the single producer of every row both the bell and Home render, and its returned object maps id, notification_id, receipt_id, type, title, body, action_url, is_read and created_at — not actor_name. - No consumer reads it.
InboxPopover renders title, body and created_at; Home's action centre does not read it either.
Note the field name also occurs on a different shape — the sys_activity row that sharedUserFeeds.ts maps to ActivityItem (user: String(r.actor_name ?? '')), and the ACTIVITY_ROW fixture in AppHeader.inboxVariant.test.tsx. Those are live and are not this field; a grep for actor_name alone will conflate the two.
Why this is only an observation
After objectui#5190 this is the last declared-but-unfilled field on InboxNotification, so it is the same class as the pair removed there. It is milder in one respect that matters: the source pair was read by a click handler that then silently did nothing, which is what made that card a behavioural defect. Nothing reads actor_name, so there is no user-visible symptom today — the cost is the same trap for the next reader, plus the standing invitation to wire it up.
Two candidate dispositions, and choosing is a product call rather than a mechanical fix:
- Retire it — same treatment as the source pair: nothing fills it, nothing reads it, and
remove beats declare-and-maintain. - Make it live — an actor name on a notification row is a plausible UI affordance (the row could read "Li Si assigned you…" rather than just the title). That would need the producer to map it and
sys_inbox_message to carry it, which is a capability expansion nobody has asked for — worth confirming against the object definition before anyone assumes the column exists.
Notes
- Severity deliberately not judged here; nothing in the shipped tree misbehaves because of this.
- objectui#5190 deliberately did not widen into this field: its ruling scoped to
source_object/source_id, and the veto clause on that card discouraged expanding the contract question inside the fix.
Found while implementing objectui#5190 (which removed the sibling
source_object/source_idpair from the same interface). Not fixed there — the ruling on that card named the two source fields only, and the correct disposition here is not mechanically pinned. Filed unassigned as an observation.What is inconsistent
InboxNotification(packages/app-shell/src/layout/inboxGrouping.ts) declares:On the inbox path that field is dead at both ends:
mergeInboxRowsinpackages/app-shell/src/hooks/sharedUserFeeds.tsis the single producer of every row both the bell and Home render, and its returned object mapsid,notification_id,receipt_id,type,title,body,action_url,is_readandcreated_at— notactor_name.InboxPopoverrenderstitle,bodyandcreated_at; Home's action centre does not read it either.Note the field name also occurs on a different shape — the
sys_activityrow thatsharedUserFeeds.tsmaps toActivityItem(user: String(r.actor_name ?? '')), and theACTIVITY_ROWfixture inAppHeader.inboxVariant.test.tsx. Those are live and are not this field; a grep foractor_namealone will conflate the two.Why this is only an observation
After objectui#5190 this is the last declared-but-unfilled field on
InboxNotification, so it is the same class as the pair removed there. It is milder in one respect that matters: the source pair was read by a click handler that then silently did nothing, which is what made that card a behavioural defect. Nothing readsactor_name, so there is no user-visible symptom today — the cost is the same trap for the next reader, plus the standing invitation to wire it up.Two candidate dispositions, and choosing is a product call rather than a mechanical fix:
removebeatsdeclare-and-maintain.sys_inbox_messageto carry it, which is a capability expansion nobody has asked for — worth confirming against the object definition before anyone assumes the column exists.Notes
source_object/source_id, and the veto clause on that card discouraged expanding the contract question inside the fix.