diff options
| author | dakkar <dakkar@thenautilus.net> | 2024-02-11 12:21:56 +0000 |
|---|---|---|
| committer | dakkar <dakkar@thenautilus.net> | 2024-02-11 12:25:50 +0000 |
| commit | 421f8d49e5d7a8dc3a798cc54716c767df8be3cb (patch) | |
| tree | 0b8e35e34780f07667785b11551ec316d55a2607 /packages/backend/src/models/Note.ts | |
| parent | merge: fix: Update l-sushi.json5 to ensure the hashtag colour matches the mai... (diff) | |
| download | sharkey-421f8d49e5d7a8dc3a798cc54716c767df8be3cb.tar.gz sharkey-421f8d49e5d7a8dc3a798cc54716c767df8be3cb.tar.bz2 sharkey-421f8d49e5d7a8dc3a798cc54716c767df8be3cb.zip | |
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.
Diffstat (limited to 'packages/backend/src/models/Note.ts')
0 files changed, 0 insertions, 0 deletions