Ce matin de jeudi, je vous soumets une énigme intéressante. Je constate ce qui ressemble à un faux positif sur le compteur de messages non lus de mon site.
Ce qui se passe
La barre de navigation supérieure affiche « Non lus (14) ». Mais lorsque je clique dessus et que je me rends sur /unread, aucune sujet non lu n’est répertorié. La page indique qu’il ne reste rien à lire.
D’autres utilisateurs non membres du personnel rencontrent le même problème, bien qu’avec des comptes de non lus différents.
Dans l’application Discourse sur iOS, je vois également un compteur de non lus alors qu’il n’y a aucun sujet non lu, parfois avec un chiffre différent.
Plateforme : navigation web sur ordinateur de bureau et application Discourse sur iOS
Le problème persiste dans ce mode, il ne semble donc pas être causé par des thèmes ou des personnalisations de plugins côté client. Il n’y a pas de messages confidentiels dans aucun sujet, donc ce n’est probablement pas cela non plus.
Je ne peux pas non plus utiliser l’option Ignorer, car il n’y a aucun bouton Ignorer sur /unread lorsque la liste des non lus est vide.
Comportement attendu
Si la barre de navigation indique « Non lus (14) », je devrais voir 14 sujets non lus sur /unread, ou du moins quelques sujets non lus visibles.
Comportement réel
la barre de navigation indique « Non lus (14) »
/unread est vide
aucun bouton Ignorer n’est disponible
le problème persiste en mode sécurisé
Questions
Existe-t-il une méthode connue pour reconstruire/réinitialiser l’état des non lus pour un utilisateur ?
Existe-t-il une incohérence côté serveur qui peut faire persister les comptes de non lus même lorsque /unread est vide ?
Auparavant, j’ai posé la question à l’IA sur ask.discourse.org concernant ce problème, et en fin de compte, il m’a été conseillé de publier un rapport de bug ici.
Ah, les « non-lus fantômes » ont mordu votre site !
Avez-vous récemment modifié des permissions de catégorie ou déplacé certains sujets vers une catégorie sécurisée ? Quelque chose a changé l’état de suivi.
Ne voudriez-vous pas le réinitialiser pour tous les utilisateurs si d’autres rencontrent le même problème ?
Je pense que cela peut être corrigé pour tout le monde via la console Rails, mais c’est un peu délicat et je dois d’abord comprendre et tester la solution. Je suis actuellement sur mobile, mais je tenterai de publier une solution dans quelques instants si personne d’autre ne le fait.
Oui. En privé, notre équipe a travaillé sur une catégorie similaire à Documentation, qui a récemment été rendue publique une fois terminée.
Oui, tout à fait. Mon idée était de d’abord le tester moi-même, puis de corriger le problème pour tout le monde. Comme il s’agit d’un bug assez complexe à tester (du moins pour moi), je ne voulais pas faire monter les espoirs de tous tant qu’une solution fonctionnelle n’était pas trouvée.
Merci pour votre confiance. Ce matin, j’ai remarqué la version mensuelle de mai 2026v2026.05 et j’ai pensé qu’elle pourrait résoudre le problème, mais il persiste toujours. Je suis certain que l’équipe s’en occupe. Discourse est formidable.
Oh, mon Dieu. J’ai admis avoir parcouru tous les rapports de bugs #réels connexes. Pendant un instant, j’ai même envisagé de simplement masquer l’onglet « Non lus » dans la navigation et de l’ignorer. Mais cela ne résoudra rien, n’est-ce pas ? Il semble même me suivre ici sur Meta.
ok, ce script Rails agira comme un « tout marquer comme lu » global et forcera le compteur de non-lu à revenir à 0 pour tous les utilisateurs. Malheureusement, cela effacera tous les comptes de non-lus légitimes en plus des non-lus fantômes. Nous pouvons faire cela avec une commande SQL dans Rails. Notez toutefois que cela ne corrige pas le bug à la racine. De plus, c’est une bonne idée si vous avez une sauvegarde récente sous la main, mais je l’ai testé sur mon forum de développement et cela a fonctionné.
cd /var/discourse ./launcher enter app rails c
Collez le bloc entier suivant et appuyez sur Entrée.
sql = <<~SQL
UPDATE topic_users
SET last_read_post_number = topics.highest_post_number
FROM topics
WHERE topics.id = topic_users.topic_id
AND COALESCE(topic_users.last_read_post_number, 0) < topics.highest_post_number
AND topic_users.notification_level IN (2, 3, 4) -- Suivi, Surveillance, Surveillance du premier message
SQL
# exécuter la mise à jour
result = ActiveRecord::Base.connection.execute(sql)
puts "#{result.cmd_tuples} sujets non lus ont été effacés avec succès à l'échelle du site."
# forcer les navigateurs clients à supprimer leur état mis en cache et à se synchroniser avec la base de données
MessageBus.publish("/topic-tracking-state", { clear: true })
Les utilisateurs devront peut-être actualiser manuellement leur page pour voir l’état non lu effacé.
J’ai admis avoir parcouru tous les rapports de bugs 
