SubwayTooterはMisskeyのi/notificationsエンドポイントを無限にリクエストします

[tamaina]

SubwayTooterがMisskeyのi/notificationsエンドポイントを無限に叩こうとするため、Misskeyインスタンスの負荷を極端に高めています。

MisskeyのAPI制限が緩いのも問題なのですが、SubwayTooterにおいてもご対応いただきたくお願い致します。

[tateisu]

https://github.com/tateisu/SubwayTooter/releases/tag/v4.9.0

[nvisser]

Misskey 12.111.1 と Subway Tooter 4.9.2 でこの問題は解決しないようです:

[26/Jun/2022:12:57:57 +0200] "POST http://borg.social/api/i/notifications HTTP/1.1" 200 25353 "-" "SubwayTooter/4.9.2 Android/12"
[26/Jun/2022:12:57:59 +0200] "POST http://borg.social/api/i/notifications HTTP/1.1" 200 25353 "-" "SubwayTooter/4.9.2 Android/12"
[26/Jun/2022:12:58:01 +0200] "POST http://borg.social/api/i/notifications HTTP/1.1" 200 25353 "-" "SubwayTooter/4.9.2 Android/12"
[26/Jun/2022:12:58:03 +0200] "POST http://borg.social/api/i/notifications HTTP/1.1" 200 25353 "-" "SubwayTooter/4.9.2 Android/12"
[26/Jun/2022:12:58:05 +0200] "POST http://borg.social/api/i/notifications HTTP/1.1" 200 25353 "-" "SubwayTooter/4.9.2 Android/12"
[26/Jun/2022:12:58:07 +0200] "POST http://borg.social/api/i/notifications HTTP/1.1" 200 25353 "-" "SubwayTooter/4.9.2 Android/12"
[26/Jun/2022:12:58:09 +0200] "POST http://borg.social/api/i/notifications HTTP/1.1" 200 25353 "-" "SubwayTooter/4.9.2 Android/12"
[26/Jun/2022:12:58:12 +0200] "POST http://borg.social/api/i/notifications HTTP/1.1" 200 25353 "-" "SubwayTooter/4.9.2 Android/12"
[26/Jun/2022:12:58:14 +0200] "POST http://borg.social/api/i/notifications HTTP/1.1" 200 25353 "-" "SubwayTooter/4.9.2 Android/12"
[26/Jun/2022:12:58:16 +0200] "POST http://borg.social/api/i/notifications HTTP/1.1" 200 25353 "-" "SubwayTooter/4.9.2 Android/12"
[26/Jun/2022:12:58:19 +0200] "POST http://borg.social/api/i/notifications HTTP/1.1" 429 157 "-" "SubwayTooter/4.9.2 Android/12"

機械翻訳を使用しているため、スペルミスがある場合はご容赦ください。

[tateisu]

I couldn't fix this problem well because I didn't saw it myself.
I think it's probably due to my Misskey usage pattern.

In version 4.9.3, SubwayTooter no longer checks notifications to Misskey servers by default.
It is possible to return to the original behavior by changing the application settings, but the setting item clearly states that it is unstable.

[nvisser]

I guess it can't be helped, thank you for looking into it.

[tateisu]

misskey-dev/misskey#8906 (comment) にコメントしましたが、

• (A) STはPushメッセージを受け取ると通知APIにアクセスする
• (B) Misskeyは通知APIにアクセスするとPushメッセージを出すようになった

というのが今回の問題の真相です。(B)が出すPushメッセージは本当に必要なものなのでしょうか。たとえば未読位置が実際には変化していないのに「未読を更新しました」など送ってたりしませんか。 @tamaina

[tateisu]

https://github.com/tateisu/SubwayTooter/releases/tag/v4.9.4

[tateisu]

4.9.4で行った変更の動作確認。

自宅鯖にログ出力を追加して

--- a/packages/backend/src/server/api/endpoints/i/notifications.ts
+++ b/packages/backend/src/server/api/endpoints/i/notifications.ts
@@ -115,6 +115,7 @@ export default define(meta, paramDef, async (ps, user) => {
        const notifications = await query.take(ps.limit).getMany();

        // Mark all as read
+       console.log(`markAsRead=${ps.markAsRead}`);
        if (notifications.length > 0 && ps.markAsRead) {
                readNotification(user.id, notifications.map(x => x.id));
        }

ST 4.9.4 のバックグラウンド通知チェック時に markAsRead=falseが設定されていることは確認した

$ docker-compose logs -f | grep markAsRead
web_1    | markAsRead=true
web_1    | markAsRead=true
web_1    | markAsRead=false

とりあえずパラメータ指定ミスとかはないことがわかった。

しかしこのサーバだとなぜかプッシュ通知を発生させることができていないし、そもそも私の手元では肝心の問題を再現できていない。

[tateisu]

misskey-dev/misskey#8979 が入ったリリースが普及したら通知チェックを再び有効にする

[tateisu]

c096684 で通知チェックをONに戻した

[tateisu]

https://github.com/tateisu/SubwayTooter/releases/tag/v5.0.8