Skip to content
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

Closed

Conversation

kakkokari-gtyih
Copy link
Contributor

@kakkokari-gtyih kakkokari-gtyih commented Feb 13, 2024

What

Cherry-picked from https://activitypub.software/TransFem-org/Sharkey/-/merge_requests/415

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.

通知に関連するリソースが削除されているなどで破損した通知オブジェクトはクライアントに送信しないように
(通知欄が無限にリロードされる問題が改善する可能性があります)

Why

Fix #10650
Fix #13369

Additional info (optional)

Checklist

  • Read the contribution guide
  • Test working in a local environment
  • (If needed) Add story of storybook
  • (If needed) Update CHANGELOG.md
  • (If possible) Add tests

dakkar and others added 2 commits February 13, 2024 15:21
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)
@github-actions github-actions bot added the packages/backend Server side specific issue/PR label Feb 13, 2024
Copy link

codecov bot commented Feb 13, 2024

Codecov Report

Attention: 44 lines in your changes are missing coverage. Please review.

Comparison is base (034f472) 77.46% compared to head (8d68c50) 64.47%.
Report is 1 commits behind head on develop.

Files Patch % Lines
...end/src/core/entities/NotificationEntityService.ts 25.42% 44 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

github-actions bot commented Feb 13, 2024

このPRによるapi.jsonの差分

差分はこちら

Get diff files from Workflow Page

@kakkokari-gtyih
Copy link
Contributor Author

👀

@tai-cha
Copy link
Contributor

tai-cha commented Feb 20, 2024

#13412 と競合する可能性があり

@kakkokari-gtyih
Copy link
Contributor Author

#13412 と競合する可能性があり

このPRの内容を #13412 にcherry-pickして統合したほうが良いかも

@tai-cha
Copy link
Contributor

tai-cha commented Feb 20, 2024

#13412 ではユーザーチェックのみだけどこちらはノートの存在確認もしてるのねなるほど

@tai-cha
Copy link
Contributor

tai-cha commented Feb 20, 2024

このPRマージ先にマージしてdevelopを #13412 にマージして取り込む流れでいいかも

このPRを取り込んだ後に #13412 で重複チェックになる部分を削る

@tamaina
Copy link
Contributor

tamaina commented Feb 20, 2024

いつマージするかわからないので #13412 にこれを取り込むかこれに #13412 相当の機能もぶっ足しする方が良さそう

(個人的には、このPRにぶっ足しして、ついでではあるけど正直可読性上げて欲しい感じはある)

@tamaina
Copy link
Contributor

tamaina commented Feb 20, 2024

(filter周りの書き方をなんとかしてほしい

Copy link
Contributor

@tai-cha tai-cha left a 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);
Copy link
Contributor

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);
Copy link
Contributor

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);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

これも

@tai-cha
Copy link
Contributor

tai-cha commented Feb 20, 2024

ぶっ足しした方が見やすいならそうするか…(さすがにPRの粒度的にぶったししない方が見やすいと思ってた)

@tai-cha
Copy link
Contributor

tai-cha commented Feb 20, 2024

#13412 でこれを取り込んだうえで可読性をめちゃくちゃ上げた

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
packages/backend Server side specific issue/PR
Projects
None yet
4 participants