Nous rencontrons un comportement très étrange, mais pour le moment uniquement chez un seul utilisateur, lors de l’ouverture de la boîte de réception des messages.
Nous exécutons Discourse dans Docker derrière Apache avec ProxyPass. Discourse 2.6.0.beta3
Cet utilisateur ne peut pas ouvrir le volet des messages ; il y a une note indiquant « No Content » ou l’équivalent en anglais de « Keine Inhalte » — nous utilisons la version de.DE
Et lorsque l’utilisateur clique à nouveau sur l’icône des messages, disons lorsqu’il essaie d’ouvrir la boîte de réception, nous obtenons une erreur 500.
La page affiche : "error on loading: [/topics/private-messages/firstname.name.json]
Cela ne se produit que pour un utilisateur donné. Les autres n’ont pas ce problème.
Nous avons essayé de modifier les rôles de cet utilisateur, nous avons effectué des mises à jour et reconstruit l’application via le launcher. Malheureusement, l’erreur 500 persiste lors de l’ouverture de la boîte de réception.
Quelqu’un a-t-il déjà rencontré un tel comportement ? Que pouvons-nous faire ? Existe-t-il un moyen de reconstruire les messages ? Ou devons-nous les supprimer ?
Merci de nous donner quelques conseils, nous sommes actuellement perdus.
J’ai remarqué quelque chose de similaire l’autre jour, avec un nom de groupe dans /topics/private-messages-group. Il s’est avéré qu’il y avait une recherche sensible à la casse, et le nom du groupe dans l’URL était entièrement en minuscules.
Pouvez-vous vérifier si cela se comporte différemment si vous modifiez la casse dans l’URL pour qu’elle corresponde à celle du nom d’utilisateur ? (par exemple https://domain.de/u/Firstname.Name/messages)
J’espère vraiment que quelqu’un pourra nous aider avec notre problème. Comme l’a suggéré @RGJ, nous avons découvert que la situation semble être un peu plus complexe, mais nous n’avons pas encore pu résoudre le problème des boîtes de réception inaccessibles d’un seul utilisateur. Malheureusement, nous utilisons énormément les messages. Nous sommes organisés en petits groupes qui ont souvent besoin de communiquer de manière non publique. Par conséquent, les messages sont un moyen idéal pour cela.
Si vous avez besoin de plus d’informations, de logs, ou si vous savez exactement ce qu’il faut me fournir, faites-le-moi savoir et je les copierai ici.
Merci à tous pour vos conseils supplémentaires et pour avoir pris le temps de lire ce message
Bon, c’est beaucoup d’informations et je ne sais pas par où commencer. J’espère que cela pourra éclaircir notre problème. Si vous avez besoin d’informations supplémentaires, n’hésitez pas à me le faire savoir.
Merci beaucoup d’avoir pris le temps d’examiner cela !
MERCI
Le nom du bucket S3 semble être lié aux systèmes de stockage Amazon S3, n’est-ce pas ? Si c’est le cas, il ne peut probablement pas être invalide. Nous n’en avons jamais configuré. Nous exécutons Discourse dans un conteneur Docker derrière un proxy inverse Apache.
Et si le bucket S3 était invalide, ne devrait-il pas provoquer beaucoup plus de plantages, et pas seulement sur une seule route d’un seul utilisateur ?
S’il vous plaît, ne me prenez pas mal. Je suis peut-être complètement sur la mauvaise voie. Comme je l’ai dit, je ne suis pas très sûr de ce qu’est ce s3_bucket_name ou, si j’ai bien compris, pourquoi il devrait être configuré.
Puis-je le vérifier dans le panneau d’administration ou dois-je examiner le fichier docker-compose ?
Désolé pour le délai … différents fuseaux horaires et horaires de travail … vous voyez.
Mais merci beaucoup d’avoir porté votre attention là-dessus !
Comme j’ai examiné les paramètres, toutes les options S3 sont vides. Est-ce normal, selon vous, puisque nous n’utilisons pas de buckets SE ? Ou est-ce que je me trompe ?
Est-ce qu’il y a encore quelqu’un ici qui aurait une idée de ce que nous pourrions essayer ?
En fait, le problème est le suivant : l’un de nos administrateurs rencontre cette difficulté, ce qui rend la communication très compliquée, car cet administrateur ne peut ni répondre aux messages ni les consulter.
Pour l’instant, une solution consisterait à rendre à nouveau accessible la boîte de réception des messages. Existe-t-il une astuce ou une possibilité de reconstruire un compte utilisateur unique ou, je ne sais pas, de supprimer tous les messages d’un seul utilisateur ? Cela nous permettrait de repartir de zéro avec ce compte.
De plus, j’ai même pensé à supprimer ce compte, mais, d’après ce que j’ai compris, la suppression des utilisateurs n’est pas possible. Que d’autre pourrions-nous essayer pour créer un nouveau compte pour cet utilisateur et lui permettre à nouveau de participer ?
Merci de me faire part de vos idées, je suis un peu perdu ici.
Bonjour,
Il semble que je rencontre un problème similaire ici. Pour autant que nous sachions, les messages pour un seul utilisateur ne fonctionnent pas.
Avez-vous d’autres idées sur ce que nous pourrions examiner ?
Je tenterais de remplacer la condition where("user_id > 0") par quelque chose comme where("user_id = l-id-de-votre-utilisateur").
Concernant la raison pour laquelle cela se produit ? Ma supposition serait que c’est quelque chose de localisé. Personnellement, j’ai parfois des problèmes avec les guillemets, les accents, etc…
En pensant à la localisation, je me demandais si le comportement devrait changer en modifiant les paramètres d’interface de l’utilisateur ? Qu’en pensez-vous ?
Je vais essayer la solution de suppression dans les prochains jours.
En attendant, nous avons réfléchi un peu. Peut-être que quelqu’un d’autre a des idées à partager.
Une autre chose étrange est la suivante : dans la zone du panneau de messagerie, en cliquant sur l’icône de l’utilisateur puis sur l’enveloppe, tous les messages récents devraient s’afficher, n’est-ce pas ? Dans le cas de nos utilisateurs qui ne parviennent pas à ouvrir leur boîte de réception, il n’y a simplement rien ?
Peut-être que quelqu’un a des idées à ce sujet. Nous pouvons être sûrs que certaines entrées devraient y figurer.
Et une autre piste de réflexion. Nous avons toujours une sorte d’erreur SSL sur notre site. Comme je l’ai dit, nous exécutons Discourse avec Docker derrière un proxy inverse sur Apache. Mais le domaine possède bien son certificat SSL valide émis par Let’s Encrypt.
Néanmoins, nous rencontrons encore des avertissements de contenu mixte sur le site. D’une manière ou d’une autre, les logos standards et les favicons sont servis en HTTP. Nous avons supprimé les personnalisations de marque afin d’éliminer les erreurs de contenu mixte.
Donc, y a-t-il une chance que cela puisse être la cause du problème ?
Lorsque nous avons récemment accédé au point de terminaison JSON https://sub.domain.de/topics/private-messages/firstnamename.json, le résultat JSON était :
{
"status":500,
"error":"Internal Server Error"
}
Un examen plus attentif des journaux a révélé ceci :
