Bug avec les notifications de chat qui ne s'affichent pas

J’ai commencé à examiner ce code, mais je pense qu’un gros problème réside dans les « attentes ».

  • S’agit-il des notifications push ? (si oui, utilisez-vous PWA ou l’application Discourse Hub)
  • Lorsque les gens disent « ne pas être notifiés », veulent-ils dire « ne pas être notifiés des mentions dans une notification push » ?
  • L’attente est-elle d’être notifié d’une @mention via une notification push alors que vous êtes déjà en ligne ?

Il y a une grande famille de ce que je considérerais comme des problèmes connus que nous pouvons améliorer.

  1. Dans PWA, si nous essayons de pousser 3 fois en 24 heures et que cela échoue (en raison de la connectivité au distributeur de messages ou autre), nous allons tuer les abonnements et ne pas alerter l’utilisateur sur quoi que ce soit.
  2. Dans Hub, les notifications push ne sont disponibles que pour les clients hébergés par Discourse.
  3. Il y a des problèmes de séquencement où une notification peut être manquée lors de la modification d’un message de chat car nous déclenchons une notification push à partir d’une transaction.
  4. Nous avons un « Débouncing » de 1 minute qui est configurable, mais déroutant. Je viens d’être mentionné mais je n’ai pas reçu de notification push. push notification time window (fenêtre de temps de notification push). Cela a provoqué : @mention, je visite l’application dans les 60 secondes. Pas de @mention.
  5. Si vous @mentionnez un utilisateur sur un canal qu’il ne suit pas, il ne recevra pas la mention. (par conception)

Honnêtement @lindsey / @j.jaffeux / @pmusaraj, j’ai l’impression que « devenir bruyant » entraînerait probablement la suppression de la grande majorité des problèmes que les gens rencontrent et des plaintes que nous avons vues au fil des ans concernant les notifications de chat.

  • Pousser toujours les notifications @mention immédiatement (par défaut du site) ; les sites qui souhaitent un délai peuvent le configurer.
  • Pousser toujours les notifications @mention depuis TOUS les canaux, n’exclure que les canaux que les utilisateurs ont explicitement mis en sourdine (ou pour lesquels ils n’ont pas la permission de voir) ; cela correspond au comportement sur le forum.
  • Il y a quelque chose d’étrange dans update_message.rb qui publie un message dans le cadre d’une transaction. (dans les environnements multi-threadés, cela peut être manqué)
  • Si nous avons tué un abonnement dans une PWA, affichez une bannière sur la PWA indiquant - les notifications push ne sont pas configurées, souhaitez-vous les configurer ? Peut-être ne tuer qu’après 1 semaine / 2 semaines au lieu de 1 jour.
  • Les balises push sont dédupliquées par canal, hostname-chat-mention-general… ce n’est pas idéal pour les mentions car nous nous regroupons par canal et cela peut être déroutant si 4 personnes différentes vous ont mentionné à des moments différents sur le canal.
  • Toujours envoyer des notifications même si l’utilisateur est en ligne (par défaut) - permettre aux utilisateurs de remplacer ce comportement s’ils le souhaitent.
  • La cerise sur le gâteau serait de prendre en charge les notifications push de première classe sur tous les sites pour les personnes ayant un identifiant Discourse configuré (via Discourse ID) - cela donnerait à Hub une sensation cohérente sur tout.

En gros, supprimez par défaut beaucoup de la logique « oops nous n’aurions pas dû vous notifier ».


Complètement désactivé lors de la mise à niveau de Discourse, pour les auto-hébergeurs, cela peut certainement être dû à des problèmes de connectivité à la passerelle de notification push. Peut-être que les mises à niveau sur certains serveurs prennent des jours, peut-être est-ce un intranet pendant 24 heures pour une raison quelconque.


Code pertinent (via Gemini 3 pro)

Les abonnements PWA sont tués

La logique qui tue les abonnements après 3 échecs en 24 heures se trouve dans la méthode handle_generic_error.

Débouncing des notifications push / Vérification en ligne

La logique qui vérifie si un utilisateur est en ligne (« debounce ») et saute la notification push est située de manière centrale ici. Cela dépend de SiteSetting.push_notification_time_window_mins.

Chat : Problèmes de séquencement des transactions

Le service UpdateMessage enveloppe l’étape publish dans une transaction de base de données. Cela peut provoquer des conditions de concurrence où le travail de notification tente de lire le message avant que la transaction ne soit validée.

Chat : Mentions sur des canaux non suivis

Le code filtre explicitement pour following: true lors du traitement des mentions pour les canaux publics, empêchant les notifications pour les utilisateurs qui ne suivent pas le canal.

Chat : Balises de notification push

La logique de génération de balises qui déduplique les notifications par canal (les regroupant) est définie ici :

4 « J'aime »