Repository navigation
[console] InboxPopover 通知页签恒为空:sys_inbox_message 有未读行、REST 正常返回、Home 卡片可渲染,弹层打开不发请求且过滤成空(rc.5 回归,rc.3 正常) #4110
Description
Activity
Triage:
pm:queue(objectui local backlog — no domain labels by protocol).- Classification: concrete rc.5 regression with a minimal repro independent of the reporting app (empty-db dev + one MessagingService emit + login). The fault isolation is strong: rows land in all three tables,
/api/v1/notificationsreturns the item unread, the Home card renders from the samesys_inbox_messagequery — only the bell popover filters to empty, and it issues no request on open. Suspected landingpackages/app-shell/src/layout/InboxPopover.tsx— present onorigin/main@1b6188d(wired fromAppHeader.tsx:938); the popover-side filter/dedup ((topic, title) dedup of 消息中心:重复通知的分组/去重/折叠(scheduled digest 每分钟一条把收件箱刷屏) #2765, or topic/source fan-out) is where to look first. fix(app-shell): surface the bell badge's notifications + approvals breakdown in the inbox popover #4073 (badge split, merged today) was checked by the reporter and is unrelated. - Dedup: [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 (hardcoded inbox/activity routes) and objectstack#6448 (rows withoutnotification_idunmarkable) are distinct inbox-family cards. Clean. - Note for the objectui whole-repo seat: regression window rc.3 → rc.5 on a shipped console surface, with an external app blocked on it — reads like your board's class ①; target grading is yours.
本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
- Classification: concrete rc.5 regression with a minimal repro independent of the reporting app (empty-db dev + one MessagingService emit + login). The fault isolation is strong: rows land in all three tables,
CLAIM (objectui whole-repo seat PM, session
session_017Qqyix2QcnpUC9XeYVDzx3) — dispatching a dev agent now.- Branch:
claude/issue-4110-inbox-popover-filter· worktreeobjectui-issue-4110(M container) - Scope: locate and fix the rc.3→rc.5 regression that makes InboxPopover's 通知 tab filter shared
sys_inbox_messagedata to empty; regression test pinning the reporter's emit shape rendering in the tab. - File surface:
packages/app-shell/src/layout/InboxPopover.tsx+ the inbox hooks/dedup it uses + their tests. NOT in surface:resolveActionParams*(held by #4163p1's train), Studio dock (held by Console AI chat (ADR-0057) — post-cleanup UX follow-ups #2477), action menus (held by finding(components): anautoTriggeraction that spills past action:bar's maxVisible lands in action:menu, which never runs it — deep link consumed, nothing triggered #4162). - Named suspects from the card + triage: 消息中心:重复通知的分组/去重/折叠(scheduled digest 每分钟一条把收件箱刷屏) #2765's (topic, title) dedup, topic/source tab fan-out. fix(app-shell): surface the bell badge's notifications + approvals breakdown in the inbox popover #4073 already exonerated by the reporter.
本单为外部 app 阻塞项(rc.5 回归),验收后走正常 ready+auto-merge。
Generated by Claude Code
- Branch:
ACCEPT (objectui seat PM, session
session_017Qqyix2QcnpUC9XeYVDzx3, review of record) — PR #4199.The dev followed the evidence past both the triage pointer and the filing's own version window, and the relocated diagnosis is airtight:
- The popover is innocent. Its 「全部」 sub-filter applies no predicate at all, so 「全部」=「暂无通知」 proves the component was handed an EMPTY array — no 消息中心:重复通知的分组/去重/折叠(scheduled digest 每分钟一条把收件箱刷屏) #2765 dedup or topic fan-out can produce that. The emptying gate is one level up:
AppHeader.tsx's inbox poller bails on!isApp, and the bell renders on HomeLayout (variant="home"), OrganizationsLayout, and AiChatPage — where the effect returns before issuing any request. Home's To-do card reads the same table throughuseHomeInbox, which has no such gate: one page, one card rendering the notification, one dead bell. Your own trace confirms it, @baozhoutao — the single observed request wastop=5(that ISuseHomeInbox(5)); the bell's own$top:20+ receipt reads are absent because they never fired. - Not an rc.3→rc.5 regression:
git log -S+ blame date the gate to20255e5411(2026-05-18) — it arrived WITH the bell feature. The Home bell has never polled. The passing 2026-07-31 e2e almost certainly asserted the popover on an APP page, where the bug does not reproduce (that case is the green control in the new tests, before and after). @baozhoutao: if you can show the bell working ON HOME under rc.3, that is a second, platform-side cause this PR does not address — please say so here with the evidence. - Fix: drop
isAppfrom that gate and its dep array — the inbox is user-scoped, not app-scoped (the flag exists for presence avatars/connection dot, which are). Red-first per-variant tests with the app variant as the never-broken control; reverse verification (gate re-inserted → 5 red / control green, as predicted); the empty-state case asserts the READ happened, not just the copy, so it cannot pass vacuously. Full app-shell suite + CI converged 20/20, real changeset.
Residual: the SAME gate still sits on the approvals + presence/activity polls, so those bell tabs stay dead off-app and the badge now differs Home-vs-app — correctly filed as #4197 with its trade-off (duplicate reads) rather than folded in. Strictly-better intermediate state; #4197 triaged separately. Flipping ready + auto-merge.
Generated by Claude Code
- The popover is innocent. Its 「全部」 sub-filter applies no predicate at all, so 「全部」=「暂无通知」 proves the component was handed an EMPTY array — no 消息中心:重复通知的分组/去重/折叠(scheduled digest 每分钟一条把收件箱刷屏) #2765 dedup or topic fan-out can produce that. The emptying gate is one level up:
Part of steedos-labs/os-project-titanwind-ehr#976
现象
PC Console 顶栏铃铛弹层(InboxPopover)的「通知」页签恒为空——「未读」显示「已读完所有通知」、「全部」显示「暂无通知」,而同一时刻、同一会话:
sys_notification/sys_inbox_message/sys_notification_receipt(state=delivered);GET /api/v1/notifications返回该条,read:false、unreadCount:1。预期(契约:ADR-0030 / #1429「Console bell 重指
sys_inbox_message+ receipts」):弹层「通知」页签列出该用户的收件箱通知。实际:通知发得出、存得下、Home 卡片和消息中心都看得见,唯独铃铛弹层渲染为空。
最小复现(不依赖我们的 app)
@objectstack/*17.0.0-rc.5 空库起 dev;{topic, audience:[userId], payload:{title, body, url}, dedupKey, source}(payload.url为 SPA 内部路由/apps/.../record/...);确认三表有行、receiptstate=delivered;「通知」页签为空,与通知条数无关(1 条或多条同样为空)。
已排除的成因(app 侧排查记录)
/api/v1/notifications返回该条organization_id为 null 被组织域过滤organization_id刷成当前组织后重测,弹层仍空sys_inbox_message查询,渲染正常关键观测(落点推断)
打开弹层时,弹层未发出任何通知相关网络请求——数据在页面加载时已由
GET /api/v1/data/sys_inbox_message?top=5&sort=-created_at&filter=[["user_id","=","(uid)"]]取回,Home 待办卡片就是用这份数据渲染成功的;弹层拿到同一份数据后过滤成空。
据此判断落点在
packages/app-shell/src/layout/InboxPopover.tsx一侧的筛选/渲染层(是否与 #2765 的 (topic, title) 去重、或按 topic/来源字段的分流有关,请平台侧定位)。
已核对今日合入的 #4073:只动徽章拆解的展示层,与本症状无关。
版本窗口(回归)
@objectstack/*@17.0.0-rc.5(cli / runtime / objectql / spec / driver-memory 全 rc.5 精确锁版;npm 上 rc.5 即最新,已确认无更新版本可试);我们没做什么
app 侧零绕行、零补丁:业务通知继续走正规 MessagingService emit 扇出,不直写表、不自建弹层。受影响面:该 app 30+ 处业务 Hook 的站内通知在 PC 端失去最主要触达入口,用户只能靠 Home 卡片或主动进消息中心发现新消息。app 侧 issue(steedos-labs/os-project-titanwind-ehr#976,私有仓,含三张对照截图)挂起等本单。