C’est très probablement juste la faute de Discourse. Ils n’envoient tout simplement pas de notifications si vous avez utilisé le site il y a un certain nombre de minutes. Mais sans aucun moyen pour les utilisateurs finaux de le voir, cela rend simplement les notifications peu fiables. Mais je vous assure, j’ai reçu des notifications push iOS pour ces deux messages. Elles peuvent fonctionner, tant que vous savez qu’il ne faut jamais leur faire confiance.
Je pense que le problème est inverse. Ne pas utiliser le site sur mon téléphone assez souvent semble mettre fin à la réception de toute notification.
Peut-être, mais nous devinons tous. L’essentiel est que Discourse fournisse une journalisation adéquate aux utilisateurs finaux. Quelles notifications Discourse a-t-il envoyées ? Quelles notifications Discourse a-t-il décidé de ne pas envoyer ?
Lorsque la PWA reçoit une notification, elle peut en faire un journal local dans IndexedDB sur l’appareil. Les utilisateurs doivent pouvoir consulter ce journal et le corréler avec le journal du serveur, pour voir quand/si Discourse a envoyé la notification push mais que l’appareil ne l’a pas reçue.
Mais, dans l’ensemble, je dirais : ne supposez pas que le problème est la faute d’Apple, et surtout ne supposez pas qu’il suffit d’attendre iOS 18. Nous avons besoin que Discourse fasse un travail ici, sinon rien ne s’améliorera jamais.
Cela me semble être une journalisation très, très verbeuse :
Un journal verbeux ici, c’est probablement assez facile :
« Ignoré la notification de Sam concernant « payload » car Sam était en ligne.
Mais si vous voulez juste déboguer cela, pourquoi ne pas définir SiteSetting.push_notification_time_window_mins sur 0 ?
Et alors le niveau de journalisation suivant devient très, très verbeux :
- Ignoré la notification car l’utilisateur avait activé la fonction « ne pas déranger »
- Délai d’attente du fournisseur de notification push discourse/app/services/push_notification_pusher.rb at cacaa90f4d01452358322ea8b5564f15f4816c74 · discourse/discourse · GitHub
- Abonnement expiré
- Erreur de réponse
Beaucoup de choses différentes peuvent mal tourner… bien qu’à tout moment, vous puissiez probablement utiliser DE pour valider : regardez dans la table push_subscriptions pour les abonnements web push à jour.
1 « J'aime »
Permettez-moi de commencer par dire que, de mon point de vue, le problème est que des gens écrivent ici et sur mon forum, disant « Je pense que les notifications push ne fonctionnent pas correctement », et d’autres utilisateurs interviennent en disant : « Oui ! Moi aussi ! Les notifications doivent être cassées/peu fiables ». Parfois, ils blâment Apple, parfois ils blâment Discourse, mais ils s’accordent tous à dire que les notifications push de Discourse sont peu fiables.
J’aimerais pouvoir enquêter moi-même sur ces cas, en disant « vous n’avez pas reçu la notification de 12h31 sur votre téléphone, et voici pourquoi… », mais je ne crois pas que ce soit actuellement possible.
Oui, beaucoup de choses différentes peuvent mal tourner, y compris des choses côté client, que je ne peux pas enquêter dans DE.
- Le Service Worker a-t-il reçu l’événement push ?
- Le Service Worker a-t-il appelé
showNotification? - L’autorisation
showNotificationa-t-elle été accordée, oushowNotificationn’a-t-il rien donné ? - L’appareil lui-même était-il réglé sur Ne pas déranger ?
J’aimerais beaucoup avoir une documentation pour les administrateurs expliquant comment utiliser DE pour diagnostiquer une défaillance de push, du moins en ce qui concerne la vérification si la notification est passée.
Mais je pense qu’il serait également incroyablement utile de conserver un journal côté client que les utilisateurs pourraient m’envoyer, me permettant de le comparer au journal DE.
D’une part, au moins la moitié des personnes qui se plaignent de cela ne sont pas des administrateurs de leur forum. C’est pourquoi nous avons besoin que Discourse implémente ceci :
Mais, oui, je soupçonne que régler cela sur 0 éliminera 80 % des plaintes « ça ne marche pas ».
Dans l’ensemble, la confiance des utilisateurs dans les notifications Discourse est assez faible. Plus ce problème est facile à rechercher pour les administrateurs (et même pour les utilisateurs finaux), plus les notifications Discourse seront fiables.
4 « J'aime »
Je suis un peu confus à propos de cette partie, nous envoyons vers une URL directement depuis le serveur…
Voici mon raisonnement. Regardez ce que disent les utilisateurs dans ce fil de discussion.
Ces messages semblent impliquer que le problème pourrait être la faute d’Apple. Peut-être que Discourse envoie vers l’URL, mais ensuite, pour une raison quelconque, Apple ne délivre pas la notification. Pourquoi cela pourrait-il être ?
- Peut-être qu’Apple renvoie un code 4xx ou 5xx au job de notification, et Discourse doit renvoyer.
- Peut-être qu’Apple a reçu le message, mais est incapable (ou ne veut pas ?) de le délivrer à l’appareil.
- Peut-être que l’appareil a reçu le message, mais qu’Apple ne déclenche pas l’événement
pushpour le service worker. - Peut-être que le service worker a reçu l’événement
push, mais qu’il y a un bug et qu’il n’a pas appeléshowNotification(probablement pas celui-ci, ce serait trop évident… ?) - Peut-être que le service worker a reçu l’événement
pushet a appeléshowNotification, mais qu’Apple a refusé d’afficher une notification visible. Il y a en fait beaucoup de raisons pour lesquelles cela pourrait se produire :- L’appareil est réglé sur Ne pas déranger (mais la notification devrait éventuellement apparaître dans le Centre de notifications, dans ce cas, je pense)
- L’autorisation a été accordée à un moment donné, mais est maintenant révoquée (le PWA peut détecter ce cas et l’enregistrer !)
- L’utilisateur pourrait avoir configuré l’application avec des paramètres de notification étranges, de sorte qu’elle ne pousse que vers le Centre de notifications mais n’affiche pas de bannière
- … ou Apple refuse d’afficher le message pour une autre raison de politique (peut-être qu’ils pensent que la notification est du spam ?), et peut-être qu’ils seront plus généreux dans une future version d’iOS.
Et cela sans même considérer les raisons pour lesquelles Discourse lui-même pourrait ne pas envoyer la notification (Ne pas déranger, filtres de notification, push_notification_time_window_mins).
Si tout ce que nous pouvons dire est : « Eh bien, à 12h31, Discourse a envoyé une notification avec l’ID XXX à Apple, et Apple a renvoyé un code d’état 201 Created, mais nous n’avons aucune idée de ce qui s’est passé après », alors ces utilisateurs/administrateurs n’auront aucun moyen d’enquêter davantage. Nous devrons simplement blâmer Apple et abandonner les notifications push. (« Peut-être que les notifications push web d’iOS 18 en 2024 feront l’affaire. »)
Au lieu de cela, nous devons être capables de dire : « Vos journaux sur l’appareil montrent qu’à 12h33, le service worker s’est réveillé avec un événement push pour la notification ID XXX, et a appelé showNotification, et nous pouvons voir via l’API de notification qu’Apple dit que l’autorisation de showNotification pour cette notification XXX a été accordée. »
(Je pense aussi qu’il devrait y avoir un bouton « envoyer une notification de test » sur la page https://meta.discourse.org/my/preferences/notifications qui vous permet de planifier une notification dans le futur, par exemple N minutes ou N heures dans le futur, permettant aux utilisateurs de tester le cas « ça ne fonctionne pas après quelques heures ».)
3 « J'aime »
De mon côté, je n’ai pas pu reproduire cela sur mon site de staging. Les notifications y fonctionnent sans problème. Le problème vient de mon site de production. Les notifications cessent de fonctionner en quelques heures à chaque fois que je les active. Ma seule théorie est que le volume des notifications push pourrait être un problème ? Mon site de production est très actif et compte plus de 50 000 membres, donc beaucoup de notifications sont envoyées à mon compte utilisateur (et en général).
Alors @WorldIsMine et moi avons fait une petite expérience.
- nous avons attendu que ses notifications cessent de fonctionner
- nous avons vérifié que son abonnement push était toujours dans la table
push_subscriptions
- j’ai envoyé une notification push depuis la console Rails et je me suis assuré de logger toutes les exceptions
u = User.find(1)
payload = { excerpt: "Test", "translated_title": "Test!" }
PushNotificationPusher.push(u, payload)
- il n’y a pas eu d’exception
- il ne l’a pas reçue
- (pour vérifier, j’ai pu m’envoyer une notification push à moi-même)
Donc, c’est quelque chose du côté d’Apple ? Qu’est-ce que cela pourrait être ?
5 « J'aime »
Avez-vous accès à un Mac pour tester dans Safari sur macOS ? Vous pourriez y configurer les outils de développement pour déboguer le service worker.
1 « J'aime »
D’après ce que je comprends, il n’y a pas de service worker impliqué ici.
Non, toutes les notifications push web nécessitent un service worker sur iOS. Sending web push notifications in web apps and browsers | Apple Developer Documentation
Ok, hors de ma portée, je n’ai malheureusement aucune expérience de ce côté client, et je n’ai pas de Mac à ma disposition.
Au moins, nous avons écarté le côté serveur.
Aha ! Je pense avoir trouvé au moins un bug avec ceci, signalé dans un fil de discussion séparé.
7 « J'aime »
Autant j’espérais que votre correction améliore les choses, autant je ne suis pas sûr.\n\nMeta a été déployé avec elle il y a une semaine. J’ai activé les notifications en direct sur mon PWA iPhone. Aujourd’hui… elles ont tout simplement cessé de fonctionner.\n\nElle a été créée le 5 janvier.\n\nJ’essaierai de déboguer cela avec un script pour voir ce qui la fait planter et combien de temps cela dure, mais beaucoup de choses pointent ici vers Apple qui a simplement un bug en quelque sorte.\n\nPlus j’y pense, plus je pense que Discourse Hub est la solution maintenant pour les appareils Apple.
3 « J'aime »
Merci d’avoir suivi cela !
Avez-vous cliqué sur des notifications ? Je demande car je me demande si Apple désactive automatiquement les notifications Web si vous en avez reçu un certain nombre sans en avoir cliqué sur aucune.
1 « J'aime »
Nous avons toujours besoin de ces fonctionnalités pour analyser les échecs :
- Instructions sur la façon d’utiliser l’Explorateur de données pour voir l’historique des notifications push.
- Journaux sur l’appareil, afin que nous puissions extraire ces journaux et les corréler avec les journaux côté serveur.
Les journaux doivent inclure les horodatages de tous les événementspush, y compris la charge utile complète, ainsi que le statut deNotification.permission. - Bouton « Envoyer une notification de test » qui met en file d’attente une notification pour N minutes/heures dans le futur.
6 « J'aime »
Notez que mes notifications PWA fonctionnent parfaitement depuis 3 semaines sur meta
8 « J'aime »
Voici une mise à jour inquiétante, qui indique que nous avons encore des ennuis de ce côté-là :
3 « J'aime »
Pour information, la nouvelle que @nathank a rapportée ci-dessus a été entièrement confirmée par Apple.
Dans un acte de conformité effrontément malveillante avec le Digital Markets Act de l’Union européenne, qui vise à apporter plus d’ouverture et de concurrence aux plateformes numériques, Apple a décidé de tuer les PWA dans l’UE avec son prochain Safari iOS 17.4.
Cela empêchera l’installation des PWA sur l’écran d’accueil, l’utilisation des notifications push, la synchronisation en arrière-plan, et interférera avec le stockage hors ligne et plus encore. Et cela aura un impact mondial au-delà de l’UE, étant donné que les entreprises seront beaucoup moins susceptibles d’investir dans les Web Apps, et les PWA en particulier, si les utilisateurs d’iPhone dans l’UE ne peuvent pas les utiliser.
Je dois penser que cela constituera un obstacle majeur pour de nombreuses communautés Discourse, et pour Discourse lui-même. Si c’est le cas pour vous, je vous recommande vivement de remplir ce sondage du groupe Open Web Advocacy. Ils mènent la lutte contre cela, travaillant à informer l’équipe du DMA de toutes les implications de ces politiques et d’autres sur le développement Web. Ils essaient de toute urgence de recueillir des témoignages et des données auprès des entreprises qui seront affectées par ces changements, afin de pouvoir donner au DMA de meilleures informations pour riposter.
Veuillez visiter cette page pour en savoir plus, remplir leur sondage sur l’impact de ces changements sur votre entreprise, et faire passer le mot ! Il serait particulièrement excellent que Discourse puisse informer ses utilisateurs du changement à venir, afin qu’ils puissent chacun se connecter avec OWA pour expliquer comment cela affecte leurs entreprises et leurs communautés.
7 « J'aime »