「プッシュ通知の更新をしました」という通知が点滅し続ける

[TranslucentFoxHuman]

💡 Summary

僕はMisskey 12.111.1のインスタンスを運用しています。
ブラウザでMisskeyを開くと、「プッシュ通知の更新をしました」という通知が、Misskeyを開いている間高速で点滅し続け、CPUに負荷をかけ、画面の一部を邪魔します。

🥰 Expected Behavior

このような通知は表示されるべきではありません。

🤬 Actual Behavior

高速に通知が表示され続けます。

📝 Steps to Reproduce

1. プッシュ通知を有効化します。
2. ブラウザでMisskeyを開きます。

📌 Environment

Misskey version: 12.111.1
Your OS (クライアント): Ubuntu 20.04
Your OS (サーバ): Debian 11
Your browser: Firefox 101.0.1

[rinsuki]

related: #7667

やっぱ既読消すのやめたほうがいいんじゃないかなあ

[rinsuki]

操作ミス

[rinsuki]

なんか Command + Enter 押すと close with comment になってしまう

[syuilo]

readNotifications とか readAllNotifications あたりの処理消せば解決する？

[tamaina]

Related: #8824

[tamaina]

@TranslucentFoxHuman 「Misskeyをブラウザで開いている間」というのは、Misskeyを開いている間ずっと起きますか？それともMisskeyを開いた直後だけそうなりますか？
（後者は想定された動作ですが、前者は想定されていない動作です）

[TranslucentFoxHuman]

このイシューを投稿した当時は、Misskeyを表示している間は常に表示され続けました。
現在は、開いた直後に発生し、その後は落ち付きます。

この間、Misskeyの更新やFirefoxの更新などの一切の更新はしていません。

[tamaina]

@TranslucentFoxHuman SubwayTooterはご利用ですか？SubwayTooterのバグが原因であると考えます。

[TranslucentFoxHuman]

SubwayTooterは使用しています。SubwayTooterでも同様に通知が点滅する現象がありました。

SubwayTooterのバグが、別なクライアントでの動作にも影響を及ぼすのですか?

[tamaina]

Yes. See #8835 and tateisu/SubwayTooter#191.

Duplicate of #8824

[TranslucentFoxHuman]

ありがとうございます。
確かに、Subway Tooterを起動すると、デスクトップでその通知が点滅することを確認しました。
今は、自分が使用しているSubway Tooterが更新され、そのバグが解消されるまでSubway Tooter上で自Misskeyからログアウトしようと思います。

ありがとうございました。

[tateisu]

これは誰かが収集したSTのADBのログです。
https://bcome.nl/logcat3.txt

$ grep "PUSH_MESSAGING" logcat3.txt  |wc -l
11
$ grep https://borg.social/api/i/notifications logcat3.txt |wc -l
11

Misskeyサーバは WebPush メッセージをSTのアプリサーバに大量に送っていませんか？ アプリサーバはFCM経由でそれをSTに伝えました。STはその数だけサーバにAPIリクエストを行いました。

[tateisu]

実際にクリアした未読がある(SQL的にはupdateの戻り値 >0である) 場合に未読クリアのWebPushを送るべきではないでしょうか。

[rinsuki]

っぽい

misskey/packages/backend/src/server/api/endpoints/i/notifications.ts

Lines 132 to 135 in 4bff552

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

misskey/packages/backend/src/server/api/common/read-notification.ts

Lines 8 to 24 in 4bff552

	export async function readNotification(
	userId: User['id'],
	notificationIds: Notification['id'][]
	) {
	if (notificationIds.length === 0) return;
	// Update documents
	await Notifications.update({
	id: In(notificationIds),
	isRead: false,
	}, {
	isRead: true,
	});
	if (!await Users.getHasUnreadNotification(userId)) return postReadAllNotifications(userId);
	else return postReadNotifications(userId, notificationIds);
	}

[tateisu]

根本的には、

• 「通知APIにアクセスがあると未読クリアする」は
• 「バックグラウンドで動く何かが通知APIにアクセスすることを想定していない」ので
• 「クライアントはバックグラウンドで通知APIを呼び出すべきではない」となり

Pull通知チェックをベースとして追加でPush対応したSTが4.9.3で通知チェックをデフォルト無効にしたのは正解、となります。仕方ないね。

[rinsuki]

「バックグラウンドで動く何かが通知APIにアクセスすることを想定していない」ので

というよりかは markAsRead がデフォルトで true なのでユーザーが明示的にリクエストしていない場合は markAsRead に false を指定するべきという話そう (それならデフォルト値ないほうが良い気もするけど破壊的変更すぎるか)

[tateisu]

未読クリアが後から追加されたのならmarkAsRead はデフォルトfalseであるべきでは…？ と思いますが、
とりあえずST的には markAsRead (Default:true )をfalse にして呼び出しますか…

[rinsuki]

既読付ける副作用は最初からデフォルトでONだけど https://github.com/misskey-dev/misskey/blame/2a9cba25a89b5cf2394a22696ee0fb67140076a9/src/api/endpoints/i/notifications.js#L24-L28 、これまで未読フラグがあんまり気にされていなかったので今まで誰も気づいていなかっただけっぽい (それはそれとしてread系のAPIでデフォルトで副作用が付いてくるのはちょっと…という)

[tateisu]

markAsRead:falseを追加した ST 4.9.4を作ってテストしてもらいましたが、まだプッシュメッセージが頻出するようでした。

• 彼がそのアカウントを登録したSTは１端末だけだそうです。なので他の古いSTが影響しているということはありません。
• WebUIを開いていたそうですが、それが影響するのかどうかは私には分かりません。

上のコメントで指摘されたように、実際に未読を更新した件数が０でもプッシュメッセージを送るのは、Misskeyのバグだと思います。修正していただきたいです。

[acid-chicken]

(それはそれとしてread系のAPIでデフォルトで副作用が付いてくるのはちょっと…という)

文字通り (get ではなく) read だからでは

[tamaina]

Has this been resolved? @TranslucentFoxHuman

[TranslucentFoxHuman]

今、Subway Tooterで再度ログインしました。問題は今の所起きていないように見えます。
しばらく様子を見てみます。