-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(backend): 破損した通知をクライアントに送信しないように #13284
Conversation
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 421f8d4)
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## develop #13284 +/- ##
============================================
- Coverage 77.46% 64.47% -12.99%
============================================
Files 184 981 +797
Lines 24725 110048 +85323
Branches 463 5562 +5099
============================================
+ Hits 19152 70950 +51798
- Misses 5566 37666 +32100
- Partials 7 1432 +1425 ☔ View full report in Codecov by Sentry. |
このPRによるapi.jsonの差分 差分はこちら |
👀 |
#13412 と競合する可能性があり |
#13412 ではユーザーチェックのみだけどこちらはノートの存在確認もしてるのねなるほど |
(filter周りの書き方をなんとかしてほしい |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pendingになってたけどちょうどこれ書いてた
packedNotes, | ||
packedUsers, | ||
}))); | ||
})))).filter(n => n); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
型のわかりやすさの問題で
})))).filter(NotNull);
みたいなやつのほうがいい可能性
const user = hint?.packedUsers != null | ||
? hint.packedUsers.get(reaction.userId)! | ||
: await this.userEntityService.pack(reaction.userId, { id: meId }); | ||
return { | ||
user, | ||
reaction: reaction.reaction, | ||
}; | ||
})); | ||
}))).filter(r => r.user); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ここもr.user !== null
とかで判定した方がいい説
const packedUser = hint?.packedUsers != null ? hint.packedUsers.get(userId) : null; | ||
if (packedUser) { | ||
return packedUser; | ||
} | ||
|
||
return this.userEntityService.pack(userId, { id: meId }); | ||
})); | ||
}))).filter(u => u); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
これも
ぶっ足しした方が見やすいならそうするか…(さすがにPRの粒度的にぶったししない方が見やすいと思ってた) |
#13412 でこれを取り込んだうえで可読性をめちゃくちゃ上げた |
What
Cherry-picked from https://activitypub.software/TransFem-org/Sharkey/-/merge_requests/415
通知に関連するリソースが削除されているなどで破損した通知オブジェクトはクライアントに送信しないように
(通知欄が無限にリロードされる問題が改善する可能性があります)
Why
Fix #10650
Fix #13369
Additional info (optional)
Checklist