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)

[huangyiirene]

Symptom

The console top-bar bell panel renders "No notifications" under BOTH its Unread and All filters, while at the same moment, for the same session:

• GET /api/v1/notifications returns 10 rows, including an approval.reminder;
• the home page's "Needs your attention" card does surface them.

Instrumenting the page shows the panel issues zero /api/v1/* requests when opened.

Why this is filed as a regression

Two closed cards describe this exact defect:

• [console] InboxPopover 通知页签恒为空:sys_inbox_message 有未读行、REST 正常返回、Home 卡片可渲染,弹层打开不发请求且过滤成空(rc.5 回归,rc.3 正常) #4110 — "InboxPopover 通知页签恒为空" — same symptom, both tabs empty ("已读完所有通知" / "暂无通知") while sys_inbox_message had unread rows, GET /api/v1/notifications returned them with unreadCount:1, and the Home 待办事项 card rendered them. It was itself reported as an rc.3 → rc.5 regression. Closed as completed by PR fix(app-shell): the bell polls the inbox on every console surface, not only inside an app (#4110) #4199 — "fix(app-shell): the bell polls the inbox on every console surface, not only inside an app" — i.e. the claimed fix was that the bell's inbox poll had been gated to inside-an-app contexts, and un-gating it would fill the Notifications tab everywhere.
• Console: notification bell dropdown always empty while list page / API / inbox tables show unread notifications #4156 — "Console: notification bell dropdown always empty while list page / API / inbox tables show unread notifications" — the English-language report of the same thing (bell empty; home to-do card, list page, /api/v1/notifications, sys_inbox_message and sys_notification_receipt all correct). Closed as duplicate.

The symptom is back on console 09987b68 (framework a86db175), with the same three-way contrast the two closed cards used as their oracle: API correct, home card correct, bell empty. Whatever #4199 fixed, it does not hold on this build — either the fix regressed, or it addressed only the off-app gating while a second path leaves the panel empty on the surface tested here.

One caveat for whoever picks this up

The "zero /api/v1/* requests on open" observation should not be read as the root cause on its own. Per #4225, the bell's rows arrive from a poll issued by layout/AppHeader.tsx every 10s (sys_inbox_message joined with sys_notification_receipt), not from a fetch on open — so a quiet panel-open is the expected shape post-#4199. The question the observation raises is whether that poll is running at all on this surface, and what it returns, versus the panel filtering a good payload to empty (which is what #4110's investigation concluded). Both branches are still open.

Root cause

Not located in this run. Prior art localises it to packages/app-shell/src/layout/InboxPopover.tsx (filter/render layer) and packages/app-shell/src/layout/AppHeader.tsx (the polled read) — see #4110's analysis and #4225's table of the two consumers.

Possibly-related second panel: the platform-core QA run objectstack-ai/objectstack#7514 independently found that the console home header renders a different inbox which polls sys_inbox_message instead of /api/v1/notifications, shows no badge, and claims "You're all caught up" with 9 unread. That is a distinct surface from the bell reported here, but the two share the same suspicion — a consumer reading the inbox tables directly disagreeing with /api/v1/notifications. Worth deciding whether they are one fix or two.

Reproduction

Console 09987b68, framework a86db175, examples/app-showcase, authenticated session with delivered notifications.

1. As a user with delivered notifications, confirm GET /api/v1/notifications returns rows (10 here, incl. an approval.reminder).
2. Confirm the home page's "Needs your attention" card lists them — it does.
3. Open the top-bar bell panel and switch between Unread and All.

Observed: "No notifications" under both filters. Instrumented network trace shows no /api/v1/* request issued on open.

Related open cards — cross-linked, not duplicated

• Home reads sys_inbox_message twice — the bell's poll and useHomeInbox each issue their own query #4225 (open, finding) — Home reads sys_inbox_message twice; the bell's 10s poll and useHomeInbox each issue their own query. Observation-class, both consumers correct at the time of writing — but it is the authoritative description of how the bell gets its data today, so it is the map for this fix, and a shared-feed refactor there must not re-break this panel.
• [console] Four remaining inbox/activity entries still hardcode /apps/setup/..., so a business user without setup access has no working "all notifications" or "all activity" link #4074 (open) — four inbox/activity entries still hardcode /apps/setup/..., including InboxPopover's goToAllNotifications / goToAllActivity. Adjacent surface, same component, different defect (dead "see all" links for non-setup users), not the empty-list symptom.

Source

Extracted from the QA run objectstack-ai/objectstack#7517 (framework a86db175, console 09987b6).