これはほぼ間違いなくDiscourseのせいでしょう。彼らはあなたがサイトを一定時間使用したばかりだと通知を送信しないだけです。しかし、エンドユーザーがそれを見る方法がないため、通知は信頼できません。しかし、私はこれらのメッセージの両方に対してiOSプッシュ通知を受け取ったことを保証します。それらが機能することは可能ですが、決して信頼しないことを知っている限りです。
問題は逆だと思います。最近、携帯電話でサイトを使用していないと、通知が届かなくなります。
しかし、それはすべて推測にすぎません。私たちが主に必要としているのは、Discourse がエンドユーザーに十分なログを提供することです。Discourse はどのような通知を送信しましたか？ Discourse はどのような通知を送信しないと判断しましたか？
PWA が通知を受信すると、デバイスの IndexedDB にローカルログを作成できます。ユーザーは、そのログを表示し、サーバーのログと照合して、Discourse がプッシュを送信したのにデバイスが受信しなかったかどうかを確認できる必要があります。
しかし、全体として、Apple のせいだと仮定しないでください。特に iOS 18 を待てば解決すると安易に考えないでください。Discourse がこの問題に取り組む必要があります。そうしないと、何も改善されません。
これは非常に冗長なログのように思えます：
ここでの冗長なログは、おそらく非常に簡単でしょう：
「Sam がオンラインだったため、Sam に「ペイロード」を通知するのをスキップしました。
しかし、これをデバッグしたいだけであれば、SiteSetting.push_notification_time_window_mins を 0 に設定するのはどうでしょうか？
そして、次のレベルのログは非常に冗長になります：
- ユーザーが「おやすみモード」を有効にしていたため、通知をスキップしました
- プッシュ通知プロバイダーへのタイムアウト discourse/app/services/push_notification_pusher.rb at cacaa90f4d01452358322ea8b5564f15f4816c74 · discourse/discourse · GitHub
- サブスクリプションの期限切れ
- レスポンスエラー
多くの異なることが起こり得ます…ただし、いつでも DE を使用して検証できるはずです。最新の Web プッシュサブスクリプションについては、push_subscriptions テーブルを確認してください。
「いいね！」 1
まず、私の見解では、問題は、人々がここで、そして私のフォーラムで、「プッシュ通知が正しく機能しないと思う」と書き込み、他のユーザーが「うん！私もだ！通知は壊れている/信頼できないに違いない」と付け加えていることです。時には彼らはAppleを非難し、時にはDiscourseを非難しますが、彼らは皆、Discourseのプッシュ通知は信頼できないという点で一致しています。
「12時31分の通知があなたの携帯電話に届かなかった、そしてその理由は…」と言って、これらのケースを自分で調査できれば素晴らしいのですが、それは現在不可能だと信じています。
はい、クライアント側の問題を含め、多くの異なることが起こり得ます。これはDEでは調査できません。
- Service Workerはプッシュイベントを受信しましたか？
- Service Workerは
showNotificationを呼び出しましたか？ showNotificationの権限は付与されていましたか、それともshowNotificationは何も行いませんでしたか？- デバイス自体が「おやすみモード」に設定されていましたか？
少なくとも通知が送信されたかどうかを確認できる範囲で、DEを使用してプッシュ障害を診断する方法を管理者に説明するドキュメントがあれば、非常にありがたいです。
しかし、クライアント側のログを保持することも非常に役立つと思います。ユーザーがそれを私に送信できるようにすれば、DEのログと照合できます。
まず、これについて不満を言っている人の少なくとも半数は、フォーラムの管理者ではありません。だからこそ、Discourseはこの機能を実装する必要があります。
しかし、はい、これを0に設定すると、「機能していない」という苦情の80％が解消されると予想しています。
全体として、Discourseの通知に対するユーザーの信頼は非常に低いです。管理者が（そしてエンドユーザーでさえ）この問題を調査できるほど、Discourseの通知はより信頼性が高くなります。
「いいね！」 4
サーバーから直接 URL にプッシュしているのですが、この部分について少し混乱しています。
私の推論はこうです。このスレッドでユーザーが何を言っているか見てみましょう。
これらの投稿は、問題がAppleにある可能性があることを示唆しているようです。DiscourseはURLにプッシュしているのかもしれませんが、何らかの理由でAppleがプッシュを配信していないのかもしれません。それはなぜでしょうか？
- Appleがプッシュジョブに4xxまたは5xxを返しており、Discourseは再プッシュする必要がありますか？
- Appleはメッセージを受け取りましたが、デバイスに配信できない（またはしたくない）のですか？
- デバイスはメッセージを受け取りましたが、Appleはサービスワーカーの
pushイベントを発火させていないのですか？ - サービスワーカーは
pushイベントを受け取りましたが、バグがあってshowNotificationを呼び出さなかったのですか？（おそらくこれではないでしょう。あまりにも明白すぎます…？） - サービスワーカーは
pushイベントを受け取り、showNotificationを呼び出しましたが、Appleは可視的な通知の表示を拒否しましたか？実際、これには多くの理由が考えられます。- デバイスが「おやすみモード」に設定されている（ただし、その場合、通知は最終的に通知センターに表示されるはずです）。
- 以前は許可されていたが、現在は取り消されている（PWAはこのケースを検出し、ログに記録できます！）。
- ユーザーがアプリを奇妙な通知設定で構成しているため、通知センターにのみプッシュするが、バナーは表示しない。
- …または、Appleが何らかのポリシー上の理由でメッセージの表示を拒否している（スパム通知だと考えているのかもしれません）、そして将来のiOSバージョンではより寛容になるかもしれません。
これらは、Discourse自体が通知を送信しない理由（おやすみモード、プッシュフィルター、push_notification_time_window_mins）さえ考慮していません。
もし言えることが、「12時31分にDiscourseはID XXXの通知をAppleに送信し、Appleは201 Createdステータスコードを返しましたが、その後のことは全く分かりません」ということだけなら、これらのユーザー/管理者はさらに調査する方法がなくなります。私たちはAppleを非難し、プッシュ通知を諦めるしかありません。（「おそらく2024年のiOS 18のWebプッシュ通知で解決するでしょう。」）
代わりに、「デバイス上のログによると、12時33分にサービスワーカーが通知ID XXXのプッシュイベントで起動し、showNotificationを発火させました。そして、通知APIを通じて、AppleはXXXプッシュのshowNotificationの許可が与えられたと述べていることが分かります」と言える必要があります。
（また、https://meta.discourse.org/my/preferences/notificationsページに「テスト通知を送信」ボタンがあり、将来の通知をスケジュールできる（例：N分後またはN時間後）ようにして、ユーザーが「数時間後に機能しない」ケースをテストできるようにすべきだと思います。）
「いいね！」 3
私の側では、ステージングサイトでこれを再現できませんでした。通知は問題なく機能しています。問題は本番サイトです。通知を有効にするたびに、数時間で機能しなくなります。私の唯一の理論は、プッシュ通知の量が問題になる可能性があるということですか？私の本番サイトは非常に活発で、50,000人以上のメンバーがいるため、多くの通知が私のユーザーアカウント（および一般的に）に送信されています。
@WorldIsMine と私はちょっとした実験をしました。
- 彼の通知が機能しなくなるまで待ちました
push_subscriptionsテーブルに彼のプッシュサブスクリプションがまだ存在することを確認しました
- Railsコンソールからプッシュ通知を送信し、すべての例外をログに記録するようにしました
u = User.find(1)
payload = { excerpt: "Test", "translated_title": "Test!" }
PushNotificationPusher.push(u, payload)
- 例外はありませんでした
- 彼は通知を受け取りませんでした
- （念のため、私は自分自身にプッシュ通知を送信することができました）
これはApple側の問題でしょうか？何が原因でしょうか？
「いいね！」 5
macOS Safari でテストするために Mac を利用できますか？ そこでサービスワーカーをデバッグするために開発者ツールを設定できます。
「いいね！」 1
私の理解では、ここにはサービスワーカーは関与していません。
いいえ、すべてのWebプッシュ通知にはiOSでサービスワーカーが必要です。 Sending web push notifications in web apps and browsers | Apple Developer Documentation
私の手に負えません。残念ながら、クライアント側での経験がなく、Macも手元にありません。
少なくとも、サーバー側の問題は除外できました。
なるほど！少なくとも1つのバグを発見したようです。これは別のスレッドで報告しました。
「いいね！」 7
あなたの修正で改善されることを期待していましたが、確信が持てません。
Metaは1週間展開されました。iPhone PWAでライブ通知を有効にしました。今日…それらは機能しなくなりました。
1月5日に作成されました。
スクリプトでこれをデバッグして、何が原因で壊れ、どれくらい続くのかを確認しようと思いますが、Appleに何らかのバグがある可能性が高いです。
これについて考えるほど、Discourse HubがAppleデバイスのソリューションであると強く思うようになります。
「いいね！」 3
追跡ありがとうございます！
通知をクリックしたことはありますか？というのも、Appleがクリックされていない通知を一定数受け取った場合に、Web通知を自動的にオフにするのではないかと疑問に思っているからです。
「いいね！」 1
障害を分析するために、これらの機能がまだ必要です。
- プッシュ通知履歴を表示するためのデータエクスプローラーの使用方法に関する指示。
- オンデバイスログ。これらのログを抽出し、サーバー側ログと相関させることができます。ログには、すべての
pushイベントのタイムスタンプ、完全なペイロード、およびNotification.permissionのステータスを含める必要があります。 - 「テスト通知を送信」ボタン。これは、N 分/時間後に通知をキューに入れます。
「いいね！」 6
なお、私のPWA通知は、過去3週間、metaで正常に機能していました。
「いいね！」 8
これは懸念すべきアップデートであり、この件に関してさらなる問題が発生することを示唆しています。
「いいね！」 3
FYI、@nathank が上記で報告したニュースは、Apple によって完全に確認されました。
欧州連合（EU）のデジタル市場法（DMA）に対する、あからさまに悪意のあるコンプライアンスの一環として、Apple は、デジタルプラットフォームのオープン性と競争を促進することを目的とした DMA に対し、次期 Safari iOS 17.4 で EU における PWA を廃止することを決定しました。
これにより、PWA をホーム画面にインストールすること、プッシュ通知の使用、バックグラウンド同期、オフラインストレージの干渉などが防止されます。また、EU の iPhone ユーザーが PWA を使用できない場合、企業は Web アプリ、特に PWA への投資をはるかに少なくなるため、EU 圏外にも世界的な影響を与えることになります。
これは、多くの Discourse コミュニティ、そして Discourse 自体にとって大きな障害になると考えられます。もし、あなたもその影響を受ける場合は、Open Web Advocacy グループのアンケートに回答することを強くお勧めします。彼らは、これらおよびその他のポリシーが Web 開発に与える影響について DMA チームに情報提供を行うための戦いをリードしています。彼らは、DMA が反撃するためのより良い情報を提供できるよう、これらの変更によって影響を受ける企業からの証言やデータを緊急に収集しようとしています。
詳細についてはこのページをご覧ください。あなたのビジネスにどのような影響があるかについてのアンケートに回答し、情報を広めてください！特に Discourse が、ユーザーに今後の変更について知らせ、それぞれのビジネスやコミュニティにどのように影響するかを OWA に説明できるようにすることができれば、非常に素晴らしいことです。
「いいね！」 7