Misskey's code does the same, but our groups behave differently enough
that this may be not the best choice
for example, let's say we have:
- notifications 1-5 for reaction to note A
- notifications 6-8 for reaction to note B
- notifications 9-12 for reaction to note A
- notification 13-19 for non-groupable events
- notification 20 for reaction to note A
and that events happened one every minute (so the last notification is
from 20 minutes ago)
client requests the most recent 10 notifications; we fetch
notifications 1-10, and reply:
- grouped id 6 for reactions 6-8 to note B
- grouped id 10 for reactions 1-5, 9-10 to note A
then the client requests 10 more notifications, untilId=10; we fetch
notifications 11-20, and reply:
- non-grouped notifications 13-19
- grouped id 20 for reactions 11,12,20 to note A
because we sort by id, and also the `createdAt` marks the _newest_
event in each group, the client will then show:
6 reactions to note B, 6 minutes ago
4 reactions to note A, 1 minute ago
notifications 13-19, 13 minutes to 19 minutes ago
3 reactions to note A, 11 minutes ago
I don't know how to make this work better ☹
* fix: notifications-groupedのinclude/exclude typesに:groupedを指定できてしまう問題
* refactor: 通知の取得処理を Notification Service に移動
* feat: add function to parse additional part of id
* fix: 通知のページネーションが正しく動かない問題
Redisにのページネーションで使用する時間及びidとRedis上のものが混同されていたので、Misskeyが生成するものに寄せました。
* pnpm run build-misskey-js-with-types
* chore: XADDをretryするように
* fix: notifications-groupedでxrevrangeしているのを消し忘れていた
* Never return broken notifications #409
Since notifications are stored in Redis, we can't expect relational
integrity: deleting a user will *not* delete notifications that
mention it.
But if we return notifications with missing bits (a `follow` without a
`user`, for example), the frontend will get very confused and throw an
exception while trying to render them.
This change makes sure we never expose those broken notifications. For
uniformity, I've applied the same logic to notes and roles mentioned
in notifications, even if nobody reported breakage in those cases.
Tested by creating a few types of notifications with a `notifierId`,
then deleting their user.
(cherry picked from commit 421f8d49e5)
* Update Changelog
* Update CHANGELOG.md
* enhance: 通知がミュートを考慮するようにする
* enhance: 通知が凍結も考慮するようにする
* fix: notifierIdがない通知が消えてしまう問題
* Add tests (通知がミュートを考慮しているかどうか)
* fix: notifierIdがない通知が消えてしまう問題 (grouped)
* Remove unused import
* Fix: typo
* Revert "enhance: 通知が凍結も考慮するようにする"
This reverts commit b1e57e571dfd9a7d8b2430294473c2053cc3ea33.
* Revert API handling
* Remove unused imports
* enhance: Check if notifierId is valid in NotificationEntityService
* 通知作成時にpackしてnullになったらあとの処理をやめる
* Remove duplication of valid notifier check
* add filter notification is not null
* Revert "Remove duplication of valid notifier check"
This reverts commit 239a6952f717add53d52c3e701e7362eb1987645.
* Improve performance
* Fix packGrouped
* Refactor: 判定部分を共通化
* Fix condition
* use isNotNull
* Update CHANGELOG.md
* filterの改善
* Refactor: DONT REPEAT YOURSELF
Note: GroupedNotificationはNotificationの拡張なのでその例外だけ書けば基本的に共通の処理になり複雑な個別の処理は増えにくいと思われる
* Add groupedNotificationTypes
* Update misskey-js typedef
* Refactor: less sql calls
* refactor
* clean up
* filter notes to mark as read
* packed noteがmapなのでそちらを使う
* if (notesToRead.size > 0)
* if (notes.length === 0) return;
* fix
* Revert "if (notes.length === 0) return;"
This reverts commit 22e2324f9633bddba50769ef838bc5ddb4564c88.
* 🎨
* console.error
* err
* remove try-catch
* 不要なジェネリクスを除去
* Revert (既読処理をpack内で行うものを元に戻す)
* Clean
* Update packages/backend/src/core/entities/NotificationEntityService.ts
* Update packages/backend/src/core/entities/NotificationEntityService.ts
* Update packages/backend/src/core/entities/NotificationEntityService.ts
* Update packages/backend/src/core/entities/NotificationEntityService.ts
* Update packages/backend/src/core/NotificationService.ts
* Clean
---------
Co-authored-by: dakkar <dakkar@thenautilus.net>
Co-authored-by: kakkokari-gtyih <daisho7308+f@gmail.com>
Co-authored-by: かっこかり <67428053+kakkokari-gtyih@users.noreply.github.com>
Co-authored-by: tamaina <tamaina@hotmail.co.jp>
Co-authored-by: syuilo <4439005+syuilo@users.noreply.github.com>
