Skip to content

Console: notification bell dropdown always empty while list page / API / inbox tables show unread notifications #4156

Description

@baozhoutao

Summary

The Console top-bar notification bell dropdown ("通知" / Notifications tab) always renders empty ("已读完所有通知" / "all caught up") even when the user has unread notifications, while every other surface for the same notifications shows them correctly.

For the same user, at the same moment:

  • Home "待办事项" / to-do card lists the notifications and shows an unread badge — correct;
  • The notifications list page (the object list) shows them — correct;
  • GET /api/v1/notifications returns unreadCount: 1 with read: false — correct;
  • Platform tables sys_inbox_message / sys_notification_receipt both have the rows — correct;
  • Only the bell dropdown list is empty.

Impact

  • Every in-app-notification feature (any flow that writes a notification) is invisible in the PC bell dropdown; users must go to the home to-do card to find notifications.
  • Severity: medium-high — the bell is the primary "new notification" affordance; silently empty, it reads as "nothing happened."

Environment

  • @objectstack/*@17.0.0-rc.5
  • Notifications written through the standard notification object → inbox pipeline.

Steps to reproduce

  1. Cause any notification to be delivered to a user (any flow that writes a notification / inbox message).
  2. As that user, confirm the notification exists: home to-do card shows it, the notifications list page shows it, GET /api/v1/notifications returns unreadCount >= 1.
  3. Open the top-bar bell dropdown, "通知" / Notifications tab.

Expected: the dropdown lists the unread notification(s).
Actual: the dropdown shows "all caught up" / zero items, while all other surfaces (to-do card, list page, API, sys_inbox_message / sys_notification_receipt) show the notification.

Notes

  • Isolated to the bell dropdown data source specifically — the underlying inbox/receipt data and the REST endpoint are correct, so this looks like the dropdown querying a different source or applying an over-narrow filter than the list page / to-do card.
  • Confirmed not feature-specific: reproduced with a long-standing notification type, so it is a channel-level, pre-existing behavior, not introduced by any particular notification.

Reproduced while building an ObjectStack 17 app; screen captures + API/DB dumps available on request (currently in a private project repo).

Activity

  1. os-zhuang commented on Aug 10, 2026

    @os-zhuang
    Contributor

    Triage: closing as duplicate of #4110 (kept card: #4110, already pm:queue).

    Same defect, same surface set, verified point-by-point: bell popover (InboxPopover) Notifications tab always empty while — for the same user at the same moment — the Home to-do card renders the rows, the notifications list page renders them, GET /api/v1/notifications returns unreadCount ≥ 1, and sys_inbox_message / sys_notification_receipt carry the rows. #4110 additionally pins the regression window (rc.3 green → rc.5 empty; e2e asserted the popover text on rc.3 on 2026-07-31), the key observation that the popover issues no network request and filters an already-fetched dataset to empty, and the inferred landing site (packages/app-shell/src/layout/InboxPopover.tsx filter/render layer) — strictly more diagnostic information, so it stays as the single dispatch entry. This card's rc.5 observations match #4110's window and add no new anchor.

    If you have evidence #4110 lacks (the screen captures / API-DB dumps mentioned here), please attach it there.

    本评论来自分诊座位 Routine(#5474 试点),不构成认领。


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions