The console HOME header renders a second, different inbox polling the wrong source — sys_inbox_message instead of /api/v1/notifications, no badge, "You're all caught up" with 9 unread #4235

Symptom

The console home header renders an inbox panel that disagrees with the notifications API.

• It polls sys_inbox_message instead of /api/v1/notifications.
• It shows no badge.
• It renders "You're all caught up" while there are 9 unread.
• Expected: the panel reflects /api/v1/notifications (or at minimum agrees with it), shows an unread badge, and does not claim an empty inbox while 9 unread rows exist.

⚠️ This is a DIFFERENT panel from the header bell — do not fold it into #4230

#4230 (open, bug+pm:queue) covers the top-bar bell panel — "No notifications" under both Unread and All while /api/v1/notifications returns 10 rows — itself filed as a regression of #4110 (closed completed by PR #4199) and #4156 (closed as duplicate).

These are two distinct panels with the same class of bug — a consumer reading the raw inbox tables instead of /api/v1/notifications, and disagreeing with it. A fix to one does NOT fix the other. They are separate components with separate reads: the bell's poll lives in packages/app-shell/src/layout/AppHeader.tsx and renders through packages/app-shell/src/layout/InboxPopover.tsx; the panel reported here is on the Home surface and is fed by packages/app-shell/src/hooks/useHomeInbox.ts. #4230 itself flags this second panel as "a distinct surface … Worth deciding whether they are one fix or two" — this card is the answer to that question: two panels, filed separately, cross-linked.

Treat the closed prior art as weak evidence of a fix: #4156 was closed as "duplicate" and #4110 as "completed" via #4199, yet #4230 demonstrates the bell symptom back on console 09987b68. This repo has a demonstrated pattern of defects closed as duplicate that were never actually fixed.

Should this be folded into #4225 instead? — No

#4225 (open, finding) — "Home reads sys_inbox_message twice — the bell's poll and useHomeInbox each issue their own query" — is adjacent and on the same code path, but it is not the same defect:

• Home reads sys_inbox_message twice — the bell's poll and useHomeInbox each issue their own query #4225 is explicitly observation-class, not a defect: its own body states "Both consumers show correct data today. Nothing is stale, nothing disagrees." Its cost is one redundant round trip plus an overlapping 10s poll.
• This card is a correctness defect: the panel shows the wrong answer (empty / no badge) while 9 unread rows exist.

Deduplicating two reads (#4225) would not make either read correct, and making this panel read the right source would not by itself remove the duplication. They should be sequenced, not merged: #4225's suggested route is to extend hooks/sharedUserFeeds.ts with an inbox feed and have Home derive its rows from it — whoever does that will be editing exactly the hook this card indicts, so the fixer should land the source correction and the shared-feed refactor with awareness of each other, and #4225's warning applies in both directions (a shared-feed refactor must not re-break the bell, per #4230).

Root cause

Located to the Home inbox read, not to the bell:

• packages/app-shell/src/hooks/useHomeInbox.ts — the Home surface's inbox read. It queries the object store directly (sys_inbox_message filtered by user_id, ordered by created_at desc, $top: limit default 5, plus sys_activity and an approvals count) and never touches /api/v1/notifications. Its own header comment states the query shapes "mirror AppHeader so the two never diverge" — that mirroring is of the bell's raw-table read, which is the same wrong source REGRESSION: the console header bell panel is dead again — "No notifications" under both Unread and All while /api/v1/notifications returns 10 rows (#4110 / #4156 back on console 09987b68) #4230 is about.
• packages/app-shell/src/console/home/HomeRail.tsx — HomeActionCenter is the panel that renders t('home.actionCenter.empty', ...) = "You're all caught up" (~line 117) whenever pendingApprovalsCount + notifications.length === 0, and its Card renders the count badge only when count > 0 — which is exactly the observed "no badge + all caught up" pair when the underlying read comes back empty.
• packages/app-shell/src/console/home/HomePage.tsx wires them: const { pendingApprovalsCount, notifications, activities } = useHomeInbox(); feeding HomeActionCenter.

Two caveats for whoever picks this up, recorded rather than smoothed over:

1. The QA report describes the surface as the "home header" inbox. The component identified above is the Home dashboard's action-center panel — the closest (and only) match on origin/main for the exact copy, badge behaviour and data source observed. Confirm the surface before editing.
2. There is a cross-run contradiction. REGRESSION: the console header bell panel is dead again — "No notifications" under both Unread and All while /api/v1/notifications returns 10 rows (#4110 / #4156 back on console 09987b68) #4230 (from QA run QA run · approvals (FULL area) · a86db175 · 2026-08-11 · 5 PASS / 2 PARTIAL / 1 FAIL objectstack#7517, same console 09987b68) records that the home page's "Needs your attention" card did surface the notifications — it was used there as the working control against the dead bell. This run (QA run · platform-core (FULL area) · a86db175 · 2026-08-11 · 3 PASS / 1 PARTIAL / 7 FAIL objectstack#7514) records the home panel as empty with 9 unread. Both cannot be unconditionally true, so there is a condition that decides it (which rows exist, user_id scoping, the approvals-count branch, or a genuinely different panel). Reproduce before assuming either report is stale.

Verified still on the wrong source on objectui origin/main @ bb68488 (current at filing time), not only on the vendored console 09987b68 the run used: useHomeInbox still reads sys_inbox_message directly and issues no /api/v1/notifications call.

Reproduction

Framework a86db175, vendored console 09987b68, showcase app, authenticated session with delivered notifications.

1. As a user with unread notifications, confirm the unread count independently (9 unread in this run).
2. Load the console home surface.
3. Observe the home inbox panel and the network trace.

Observed: the panel polls sys_inbox_message (no /api/v1/notifications request), renders no badge, and states "You're all caught up" while 9 unread exist.

Related

• REGRESSION: the console header bell panel is dead again — "No notifications" under both Unread and All while /api/v1/notifications returns 10 rows (#4110 / #4156 back on console 09987b68) #4230 — the bell panel, same bug class, different panel. Cross-linked, not duplicated.
• Home reads sys_inbox_message twice — the bell's poll and useHomeInbox each issue their own query #4225 — the double sys_inbox_message read on Home; same code path, different (observation-class) problem. Sequence with this card; do not merge.
• [console] InboxPopover 通知页签恒为空:sys_inbox_message 有未读行、REST 正常返回、Home 卡片可渲染,弹层打开不发请求且过滤成空(rc.5 回归,rc.3 正常) #4110 / Console: notification bell dropdown always empty while list page / API / inbox tables show unread notifications #4156 — closed prior art for the bell symptom; weak evidence of a fix.

Source

Extracted from the QA run objectstack-ai/objectstack#7514 (framework a86db175, vendored console 09987b6). Root-cause re-verification is against objectui origin/main @ bb68488.