J’ai une instance Discourse en ligne depuis une semaine, et elle présente certains des symptômes les plus étranges que je n’arrive pas à résoudre, en partie parce qu’aucune information utile n’apparaît dans les journaux.
Le symptôme le plus évident est le suivant : si je vais dans les paramètres, modifie un réglage, puis clique sur la coche verte, l’acceptation semble fonctionner et tout paraît correct. Cependant, si je rafraîchis ensuite la page des paramètres, il y a de fortes chances que l’ancien ou le nouveau réglage s’affiche. En continuant à rafraîchir, l’un ou l’autre réglage apparaît alternativement.
Pire encore, ce problème ne se limite pas à l’écran des paramètres ; la fonctionnalité même du serveur semble parfois changer. Par exemple, lors de la tentative de téléchargement d’un nouveau logo, il arrive que l’ancien s’affiche parfois, et le nouveau d’autres fois.
Pour répondre à la question évidente : non, je n’exécute pas plusieurs instances derrière un équilibreur de charge ; il s’agit d’une instance unique.
Je ne sais pas si cela est lié, mais je remarque également que le plugin Discourse Math ne se rend pas correctement. Bien que les équations s’affichent correctement dans l’aperçu, une fois le message publié, le JavaScript ne semble pas être inclus, ce qui empêche un rendu correct. Le problème mathématique n’est pas prioritaire ici, mais je le mentionne au cas où il fournirait d’autres indices.
Je suis vraiment bloqué ici. Comme les journaux semblent tous normaux, je ne sais même pas quoi publier pour obtenir de l’aide. Toute idée serait la bienvenue.
J’ai essayé cela sans succès. Il s’agit probablement d’un problème dans la façon dont je l’installe ou quelque chose de similaire.
Je suis moi-même développeur. Avez-vous une idée de ce qui pourrait être cassé lors de l’installation et provoquer cela ? Une sorte d’indice sur l’endroit où déboguer et dépanner ?
À l’origine, c’était la méthode que j’avais adoptée. Malheureusement, elle ne prend pas en charge la plupart des environnements de production de niveau entreprise dont je dispose. La plupart des frameworks gèrent, lancent et déploient des conteneurs. En raison de la nature de l’approche d’installation standard, il n’est pas possible de travailler avec ces outils et dans ces environnements.
C’est pourquoi je tente d’améliorer/corriger le processus afin qu’il puisse s’installer partout où un déploiement Docker standard est pris en charge. Bien que cet effort fonctionne en grande partie, c’est le bug que j’ai initialement signalé qui me pose problème.
Une fois que cela fonctionnera, je le publierai bien sûr pour les autres. J’ai passé l’année dernière à attendre que Discourse prenne en charge Docker standard, mais j’ai décidé de faire cette contribution moi-même. C’est si proche, mais j’espère qu’une personne plus expérimentée que moi pourra m’indiquer où chercher.
Merci, cela pourrait s’avérer très utile. Étant donné que le plugin MathJax semblait fonctionner de manière sporadique avant de s’arrêter, il est probable que le problème soit lié à JavaScript.
Je suis allé vérifier et j’ai tenté de modifier un paramètre après avoir vidé le cache, en surveillant attentivement l’onglet Réseau. Aucune erreur n’est apparue avant ou après la modification du paramètre (même si le bug s’est manifesté).
Une raison pour laquelle il n’est pas logique que la modification ne soit pas appliquée du tout réside dans le comportement observé. Je fais une modification, puis j’actualise la page et la modification semble être annulée. Cependant, si je continue à actualiser simplement (sans tenter de refaire la modification), le changement apparaît environ la moitié du temps. À chaque actualisation, il y a environ 50 % de chances que l’ancien paramètre s’affiche par rapport au nouveau.
J’ai également trouvé l’erreur suivante dans la console, mais je pense qu’elle est sans rapport ?
Impossible de trouver l’action widget actions-summary-item dans le registre
J’ai essayé cela, comme je l’avais fait auparavant. Cela n’a pas aidé. Mais je suis sceptique quant à savoir si j’étais vraiment en mode sans échec. Je suis allé à */safe-mode et j’ai obtenu la boîte de dialogue pour entrer en mode sans échec. Je l’ai acceptée. Mais ce que j’ai remarqué, c’est que le thème Material Design que j’utilise s’affichait toujours. Donc, bien que j’aie cru être en mode sans échec, peut-être n’y étais-je pas vraiment ?
Deux conteneurs : un pour Sidekiq et un pour le cœur de Discourse. Une seule instance de la paire. J’exécute PostgreSQL et Redis en tant que services hébergés sur des machines distinctes.
Oups. Désolé, c’était la question évidente à laquelle vous avez déjà répondu.
Éditer : peut-être que ce n’est pas ça non plus, mais j’ai eu un problème similaire lorsque j’utilisais une base de données Redis qui était utilisée par un autre processus.
Cela dépend de ce que vous entendez. Dans l’onglet « Réseau » de l’inspecteur pour le débogage, tout s’affiche en 200 ; la console ne contient que l’erreur mentionnée précédemment (probablement sans rapport). Dans les journaux Docker, lorsque j’effectue le réglage, je vois ce qui suit, ce qui confirme que l’opération a réussi. Pourtant, lorsque je rafraîchis la page de configuration, 50 % du temps elle affiche le paramètre ld et 50 % du temps le nouveau.
> 2019-08-20T13:14:15.960335498Z Démarrage de PUT "/admin/site_settings/categories_topics" pour 213.127.19.53 le 2019-08-20 13:14:15 +0000
> 2019-08-20T13:14:15.968667966Z Traitement par Admin::SiteSettingsController#update en */*
> 2019-08-20T13:14:15.968951769Z Paramètres : {"categories_topics"=>"25", "id"=>"categories_topics"}
> 2019-08-20T13:14:15.978407541Z Rendu du modèle de texte
> 2019-08-20T13:14:15.978607623Z Modèle de texte rendu (0,0 ms)
> 2019-08-20T13:14:15.978834745Z Terminé avec 200 OK en 10 ms (Vues : 0,6 ms | ActiveRecord : 0,0 ms)
> 2019-08-20T13:18:39.821498901Z [ N 2019-08-20 13:18:39.8209 4304/T4 age/Cor/CoreMain.cpp:1146 ] : Vérification de la nécessité de déconnecter les connexions de longue durée pour le processus 6157, application /opt/bitnami/discourse (production)
> 2019-08-20T13:18:59.866033984Z [ N 2019-08-20 13:18:59.8655 4304/T4 age/Cor/CoreMain.cpp:1146 ] : Vérification de la nécessité de déconnecter les connexions de longue durée pour le processus 5973, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:04.848923491Z [ N 2019-08-20 13:19:04.8484 4304/T4 age/Cor/CoreMain.cpp:1146 ] : Vérification de la nécessité de déconnecter les connexions de longue durée pour le processus 6018, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:08.900933057Z [ N 2019-08-20 13:19:08.9004 4304/T4 age/Cor/CoreMain.cpp:1146 ] : Vérification de la nécessité de déconnecter les connexions de longue durée pour le processus 5995, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:09.499349110Z [ N 2019-08-20 13:19:09.4989 4304/T4 age/Cor/CoreMain.cpp:1146 ] : Vérification de la nécessité de déconnecter les connexions de longue durée pour le processus 6041, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:29.645095032Z Création de la portée :open. Écrasement de la méthode existante Poll.open.
L’installation n’utilise pas la méthode standard, bien que je m’en sois servi comme guide pour apprendre. J’ai essentiellement dû écrire et modifier les fichiers Docker pour qu’ils fonctionnent avec Docker Compose. Ensuite, une fois que Docker Compose fonctionnait localement, j’ai converti la configuration en format JSON afin qu’elle puisse être utilisée avec les outils aws-cli.
Le processus d’installation est donc sensiblement différent de la méthode standard.
