Skip to content

fix(notifications): apply live READ/DELETED events to the store - #408

Open
pavlo-flamingo wants to merge 2 commits into
mainfrom
fix/notifications-live-read-state
Open

pavlo-flamingo wants to merge 2 commits into
mainfrom
fix/notifications-live-read-state

Conversation

@pavlo-flamingo

Copy link
Copy Markdown
Contributor

Problem

Mark as read / delete in one session does not reach the user's other open sessions: the New list and the unread badge stay stale until a reload, while CREATED arrives live in the same tab.

Cause

The backend has published READ / DELETED on user.<id>.notification since openframe-oss-lib #1816 — notificationIds only, no top-level id. The live bridge checked for that id before looking at eventType, so both events were dropped. This predates #404; the context refactor did not touch this path.

Fix

  • Branch on READ / DELETED before the id guard; run the existing mark-read / delete store updaters per id, then refetch the counts for ids outside the loaded window.
  • The updaters are now idempotent: the backend echoes the event back to the tab that fired the mutation, so a second pass must not duplicate a history row or decrement the badge twice. Pinned against a real relay-runtime store in notifications-read-state.test.ts.
  • /notifications registers its search-keyed connection pair, so the event reaches the table as well as the drawer.

Caveat

Verified on the wire shape (NotificationNatsPublisher.publishReadStateToUser) and unit tests, not reproduced against a live backend from this branch. The listener only publishes when spring.cloud.stream.enabled is on for the notifications service.

Marking a notification read (or deleting it) in one session left every
other open session of the same user stale - the unread list and the badge
only caught up on reload - even though CREATED arrived live in the same tab.

The backend publishes READ/DELETED on the user's NATS subject with
`notificationIds` only and no top-level id (openframe-oss-lib #1816). The
live bridge guarded on that id before looking at `eventType`, so both
events were dropped.

- Branch on READ/DELETED before the id guard and run the existing
  mark-read / delete store updaters per id, then refetch the counts for
  ids outside the loaded window.
- Make those updaters idempotent: the backend echoes the event back to the
  tab that fired the mutation, so a second pass must not insert a
  duplicate history row or decrement the badge twice.
- Let /notifications register its search-keyed connection pair so the
  event reaches the table as well as the drawer.
@pavlo-flamingo
pavlo-flamingo requested review from a team as code owners September 15, 2026 15:43
@github-actions

github-actions Bot commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

🦩 Flamingo Code Review

No findings on the current head.

Mode: advisory


Need another pass? Commits pushed after this review are not reviewed automatically.

  • Review the new commits — the commits added since this review
  • Review the whole diff again — ignoring what was already reviewed

Prefer typing? Comment @flamingo-review, or @flamingo-review full. To review every push on this pull request, add the flamingo-review-always label.

React 👍/👎 on inline comments to teach the reviewer.

Started 2026-09-15 15:43 UTC · updated 2026-09-15 15:44 UTC · workflow run

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant