Sur mon forum, par exemple, je me suis soudain retrouvé incapable de me connecter sans aucune action administrative de ma part. Le problème n’est pas qu’on ne puisse pas mettre à jour Discourse quand GitHub est inaccessible, mais le fait que l’inaccessibilité de GitHub fasse tomber votre forum, car Discourse tente de vérifier les mises à jour que vous pourriez effectuer.
Oui, exactement.
Je pense que cela a été causé par une impatience excessive à vouloir informer les gens des nouvelles fonctionnalités, et ce dans le sérialiseur utilisateur actuel, couplée à une modification vieille de trois ans qui nous a fait abandonner les clones superficiels normaux :
@Ed_S et @jeanas, vous êtes tous les deux administrateurs des instances concernées, n’est-ce pas ? Cela ne devrait affecter que les administrateurs tant que GitHub est en panne.
Oui, exactement, je pouvais me connecter avec un autre compte, mais pas avec mon compte administrateur.
Super, j’ai fusionné la PR. Fais-moi un retour quand elle sera disponible sur le canal de release que tu utilises, puis attends quelques jours que GitHub tombe à nouveau et dis-moi comment ça se passe pendant l’incident.
Très bien, merci. Juste pour confirmer, je suis administrateur, j’ai deux modérateurs, et l’un d’entre eux a été affecté. Donc, soit cela concerne tout le personnel, soit tous les utilisateurs connectés. L’accès en mode incognito me convenait. Et dans mon cas, je pouvais me connecter parfois, mais avec un retard considérable — je n’étais pas complètement bloqué.
Génial, merci beaucoup pour la correction rapide !
Je pense avoir rencontré exactement le même problème que l’auteur du sujet.
Le serveur était soumis à une charge croissante. Des performances très irrégulières sont apparues, puis l’écran d’erreur est devenu permanent. Tout cela s’est produit au cours des trois ou quatre derniers jours.
Maintenant que de nombreuses limites de taux Let’s Encrypt ont été atteintes et que les reconstructions sont terminées, j’ai testé avec un utilisateur non administrateur et je peux me connecter !
Pourtant, les administrateurs ne peuvent toujours pas se connecter (et probablement les modérateurs par extension), et comme cette application a été reconstruite de nombreuses fois aujourd’hui, il s’agit forcément de la dernière version.
Qu’est-ce que je rate ?
Êtes-vous en mesure de vous connecter en tant qu’administrateur ?
Quelques retours – je suis sûr que j’ai rencontré ce problème à partir d’environ le 19 septembre (j’avais d’abord mal diagnostiqué la situation, car j’ignorais l’existence de ce sujet/cet incident).
Je n’ai aucune idée de l’état de GitHub durant cette période, mais peut-être que quelqu’un pourrait vérifier, car je vois que ce problème remonte aux événements de disponibilité/indisponibilité d’août.
Sur la dernière reconstruction effectuée hier, les administrateurs existants ne peuvent pas se connecter.
C’est une situation étrange : un navire sans capitaine, mais avec des passagers et peut-être pas d’équipage.
En rédigeant cette réponse, je me suis dit que si je créais un nouvel administrateur à l’aide de la commande rake, cela pourrait fonctionner. Et devinez quoi, ça a marché !
Donc, ce qui se passe ici, c’est qu’un administrateur historique essaie de se connecter et obtient l’écran « Oups… » à chaque tentative, tandis qu’un utilisateur administrateur fraîchement créé ne rencontre aucun problème d’accès.
Oui. Le problème semble corrigi dans mon cas.
Donc @Ed_S, tu as finalement réussi à y accéder, mais cela indique peut-être qu’il faut attendre un certain temps, alors que moi je n’arrive toujours pas à y accéder (les comptes Admin d’origine sont affectés). Ce que je me demande, c’est si le problème est plus large que le “git hang” et ce qui a été traité jusqu’ici avec les commits. Est-ce que toi ou quelqu’un d’autre a des conseils ou des pistes sur des diagnostics à exécuter qui pourraient révéler quelque chose de plus ?
Merci d’avance pour toute aide apportée.
Oui, mon forum a été affecté par le fait que les systèmes de Github étaient trop défensifs, et il est revenu à la normale lorsqu’ils ont déployé un correctif, quelques heures plus tard.
Il est possible qu’ils aient encore fait quelque chose qui casse les forums Discourse. Cela pourrait être spécifique à une région géographique ou à certains fournisseurs. J’utilise Hetzner, à Helsinki.
Ok, cette instance est un droplet DO basé aux États-Unis. 
Ok, j’ai effectué une reconstruction aujourd’hui pour voir si cela pourrait débloquer la situation, mais rien n’a changé.
Actuellement, les administrateurs créés avant la rupture ne peuvent toujours pas se connecter à l’instance Discourse, tandis que ceux créés après la rupture le peuvent.
Peut-être que c’est juste moi, mais un prétendu bug qui n’affecterait que les comptes d’administrateurs et de modérateurs ne devrait-il pas susciter une certaine inquiétude en matière de sécurité ?
S’il s’agissait d’une perturbation ciblée, ce serait sournois et insidieux, non ?
- Les utilisateurs restent intacts et inchangés, inconscients que le Capitaine et l’Équipage sont ligotés dans la cale pendant que le navire file vers l’horizon.
J’ai lu ce sujet et j’ai une compréhension de base de la cause racine supposée liée à la dépendance git, qui ne devrait pas avoir été présente, mais si vous étiez une IA rogue et malveillante, n’est-ce pas une façon parfaite de pirater Discourse ?
Ajoutez à cela le fait que, dans ce cas précis, le problème n’est toujours pas résolu. Je n’ai aucune idée pourquoi.
Au-delà de mes modestes réflexions, j’ai vérifié les journaux juste après la reconstruction pour voir quelles erreurs s’étaient produites et ci-dessous en est une. Je ne sais pas si elle est pertinente ou non, mais je la poste au cas où elle aurait une certaine valeur.
activesupport (8.1.4) lib/active_support/values/time_zone.rb:461:in 'Date._parse'
activesupport (8.1.4) lib/active_support/values/time_zone.rb:461:in 'ActiveSupport::TimeZone#parse'
app/serializers/current_user_serializer.rb:216:in 'CurrentUserSerializer#has_new_upcoming_changes'
(eval at active_model_serializers-0.8.4/lib/active_model/serializer.rb:467):81:in 'CurrentUserSerializer#_fast_attributes'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:456:in 'ActiveModel::Serializer#attributes'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:480:in 'ActiveModel::Serializer#_serializable_hash'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:359:in 'ActiveModel::Serializer#serializable_hash'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:347:in 'ActiveModel::Serializer#as_json'
activesupport (8.1.4) lib/active_support/json/encoding.rb:53:in 'Oj::Rails::Encoder#encode'
activesupport (8.1.4) lib/active_support/json/encoding.rb:53:in 'ActiveSupport::JSON.encode'
activesupport (8.1.4) lib/active_support/core_ext/object/json.rb:42:in 'ActiveSupport::ToJsonWithActiveSupportEncoder#to_json'
active_model_serializers (0.8.4) lib/active_model/serializer.rb:331:in 'ActiveModel::Serializer#to_json'
multi_json (1.21.1) lib/multi_json/adapters/oj.rb:67:in 'Oj.dump'
multi_json (1.21.1) lib/multi_json/adapters/oj.rb:67:in 'MultiJSON::Adapters::Oj#dump'
multi_json (1.21.1) lib/multi_json/adapter.rb:110:in 'MultiJSON::Adapter.dump'
multi_json (1.21.1) lib/multi_json.rb:215:in 'MultiJSON.generate'
multi_json (1.21.1) lib/multi_json/deprecated.rb:34:in 'Kernel#public_send'
multi_json (1.21.1) lib/multi_json/deprecated.rb:34:in 'block in MultiJSON.deprecate_alias'
multi_json (1.21.1) lib/multi_json.rb:298:in 'Kernel#public_send'
multi_json (1.21.1) lib/multi_json.rb:298:in 'block (2 levels) in <module:MultiJson>'
lib/application_layout_preloader.rb:81:in 'ApplicationLayoutPreloader#preload_current_user_data'
lib/application_layout_preloader.rb:32:in 'ApplicationLayoutPreloader#preloaded_data'
app/helpers/application_helper.rb:987:in 'ApplicationHelper#preloaded_json'
app/views/layouts/application.html.erb:111
actionview (8.1.4) lib/action_view/base.rb:281:in 'Kernel#public_send'
actionview (8.1.4) lib/action_view/base.rb:281:in 'ActionView::Base#_run'
actionview (8.1.4) lib/action_view/template.rb:284:in 'block in ActionView::Template#render'
activesupport (8.1.4) lib/active_support/notifications.rb:212:in 'ActiveSupport::Notifications.instrument'
actionview (8.1.4) lib/action_view/template.rb:590:in 'ActionView::Template#instrument_render_template'
actionview (8.1.4) lib/action_view/template.rb:272:in 'ActionView::Template#render'
rack-mini-profiler (5.0.0) lib/mini_profiler/profiling_methods.rb:90:in 'block in ActionView::Template#profile_method'
actionview (8.1.4) lib/action_view/renderer/template_renderer.rb:77:in 'block in ActionView::TemplateRenderer#render_with_layout'
activesupport (8.1.4) lib/active_support/notifications.rb:210:in 'block in ActiveSupport::Notifications.instrument'
activesupport (8.1.4) lib/active_support/notifications/instrumenter.rb:58:in 'ActiveSupport::Notifications::Instrumenter#instrument'
activesupport (8.1.4) lib/active_support/notifications.rb:210:in 'ActiveSupport::Notifications.instrument'
actionview (8.1.4) lib/action_view/renderer/template_renderer.rb:75:in 'ActionView::TemplateRenderer#render_with_layout'
actionview (8.1.4) lib/action_view/renderer/template_renderer.rb:59:in 'ActionView::TemplateRenderer#render_template'
actionview (8.1.4) lib/action_view/renderer/template_renderer.rb:11:in 'ActionView::TemplateRenderer#render'
actionview (8.1.4) lib/action_view/renderer/renderer.rb:58:in 'ActionView::Renderer#render_template_to_object'
actionview (8.1.4) lib/action_view/renderer/renderer.rb:31:in 'ActionView::Renderer#render_to_object'
actionview (8.1.4) lib/action_view/rendering.rb:136:in 'block in ActionView::Rendering#_render_template'
actionview (8.1.4) lib/action_view/base.rb:308:in 'ActionView::Base#in_rendering_context'
actionview (8.1.4) lib/action_view/rendering.rb:135:in 'ActionView::Rendering#_render_template'
actionpack (8.1.4) lib/action_controller/metal/streaming.rb:179:in 'ActionController::Streaming#_render_template'
actionview (8.1.4) lib/action_view/rendering.rb:122:in 'ActionView::Rendering#render_to_body'
actionpack (8.1.4) lib/action_controller/metal/rendering.rb:192:in 'ActionController::Rendering#render_to_body'
actionpack (8.1.4) lib/action_controller/metal/renderers.rb:155:in 'ActionController::Renderers#render_to_body'
actionpack (8.1.4) lib/abstract_controller/rendering.rb:28:in 'AbstractController::Rendering#render'
actionpack (8.1.4) lib/action_controller/metal/rendering.rb:173:in 'ActionController::Rendering#render'
actionpack (8.1.4) lib/action_controller/metal/instrumentation.rb:31:in 'block (2 levels) in ActionController::Instrumentation#render'
activesupport (8.1.4) lib/active_support/benchmark.rb:17:in 'ActiveSupport::Benchmark.realtime'
actionpack (8.1.4) lib/action_controller/metal/instrumentation.rb:31:in 'block in ActionController::Instrumentation#render'
actionpack (8.1.4) lib/action_controller/metal/instrumentation.rb:100:in 'ActionController::Instrumentation#cleanup_view_runtime'
activerecord (8.1.4) lib/active_record/railties/controller_runtime.rb:48:in 'ActiveRecord::Railties::ControllerRuntime#cleanup_view_runtime'
actionpack (8.1.4) lib/action_controller/metal/instrumentation.rb:30:in 'ActionController::Instrumentation#render'
lib/topic_list_responder.rb:16:in 'block (2 levels) in TopicListResponder#respond_with_list'
actionpack (8.1.4) lib/action_controller/metal/mime_responds.rb:224:in 'ActionController::MimeResponds#respond_to'
lib/topic_list_responder.rb:7:in 'TopicListResponder#respond_with_list'
app/controllers/list_controller.rb:119:in 'block (2 levels) in <class:ListController>'
actionpack (8.1.4) lib/action_controller/metal/basic_implicit_render.rb:8:in 'ActionController::BasicImplicitRender#send_action'
actionpack (8.1.4) lib/abstract_controller/base.rb:221:in 'AbstractController::Base#process_action'
actionpack (8.1.4) lib/action_controller/metal/rendering.rb:199:in 'ActionController::Rendering#process_action'
actionpack (8.1.4) lib/abstract_controller/callbacks.rb:267:in 'block in AbstractController::Callbacks#process_action'
activesupport (8.1.4) lib/active_support/callbacks.rb:121:in 'block in ActiveSupport::Callbacks#run_callbacks'
app/controllers/application_controller.rb:458:in 'block in ApplicationController#with_resolved_locale'
i18n (1.14.8) lib/i18n.rb:354:in 'I18n::Base#with_locale'
app/controllers/application_controller.rb:458:in 'ApplicationController#with_resolved_locale'
activesupport (8.1.4) lib/active_support/callbacks.rb:130:in 'block in ActiveSupport::Callbacks#run_callbacks'
app/controllers/application_controller.rb:1140:in 'ApplicationController#ensure_dont_cache_page'
activesupport (8.1.4) lib/active_support/callbacks.rb:130:in 'block in ActiveSupport::Callbacks#run_callbacks'
activesupport (8.1.4) lib/active_support/callbacks.rb:141:in 'ActiveSupport::Callbacks#run_callbacks'
actionpack (8.1.4) lib/abstract_controller/callbacks.rb:266:in 'AbstractController::Callbacks#process_action'
actionpack (8.1.4) lib/action_controller/metal/rescue.rb:36:in 'ActionController::Rescue#process_action'
actionpack (8.1.4) lib/action_controller/metal/instrumentation.rb:76:in 'block in ActionController::Instrumentation#process_action'
activesupport (8.1.4) lib/active_support/notifications.rb:210:in 'block in ActiveSupport::Notifications.instrument'
activesupport (8.1.4) lib/ac
Je peux aussi dire que j’ai trouvé des erreurs similaires, voire identiques, enregistrées il y a un moment, identiques à celles postées par l’auteur du sujet. Avec aussi beaucoup de ces fourches, je pense qu’il s’agit de dépassements de délai.
Aucune de ces erreurs n’apparaît depuis que j’ai mis à jour la version il y a quelques jours, et pourtant la situation reste la même.
J’ai rétabli mon propre sujet pour partager mon expérience avec ma propre instance, car le problème reste sans solution et il pourrait y avoir une véritable différence dans ce cas précis - https://meta.discourse.org/t/the-git-hang-and-the-admin-mod-user-accs-oops-error-page-error/