Plantage de Git et page d'erreur « Oops » pour les comptes Admin/Mod

ActionView::Template::Error (no implicit conversion of Array into String)

J’ai reproduit le problème de l’erreur de la page Oops lors de la connexion, qui semble n’affecter que les administrateurs et, dans certains cas, d’autres comptes de personnel. Dans ce cas précis, il s’agit d’un compte administrateur, mais uniquement de ceux qui étaient pré “git hang” en tentant simplement une autre connexion.

J’ai ensuite consulté les journaux (logs), maintenant que je suis plus familiarisé avec le fonctionnement de la fonctionnalité de sortie /logs, qui est excellente !

Cette erreur apparaît comme une « erreur fatale » et a commencé le 22. Elle semble très similaire au problème de “git hang”, mais dans ce cas, elle reste non résolue malgré diverses reconstructions effectuées jusqu’à présent. Cela signifie que certains comptes administrateurs sont essentiellement verrouillés. Veuillez consulter les informations et les journaux de trace d’erreur ci-dessous :

Informations

Message

ActionView::Template::Error (no implicit conversion of Array into String)
app/serializers/current_user_serializer.rb:216:in 'CurrentUserSerializer#has_new_upcoming_changes'
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
lib/topic_list_responder.rb:16:in 'block (2 levels) in TopicListResponder#respond_with_list'
lib/topic_list_responder.rb:7:in 'TopicListResponder#respond_with_list'
app/controllers/list_controller.rb:119:in 'block (2 levels) in class:ListController'
app/controllers/application_controller.rb:458:in 'block in ApplicationController#with_resolved_locale'
app/controllers/application_controller.rb:458:in 'ApplicationController#with_resolved_locale'
app/controllers/application_controller.rb:1140:in 'ApplicationController#ensure_dont_cache_page'
lib/middleware/omniauth_bypass_middleware.rb:35:in 'Middleware::OmniauthBypassMiddleware#call'
lib/middleware/crawler_hooks.rb:13:in 'Middleware::CrawlerHooks#call'
lib/content_security_policy/middleware.rb:12:in 'ContentSecurityPolicy::Middleware#call'
lib/middleware/anonymous_cache.rb:431:in 'Middleware::AnonymousCache#call'
lib/middleware/csp_script_nonce_injector.rb:13:in 'Middleware::CspScriptNonceInjector#call'
lib/middleware/track_view_session_id_injector.rb:12:in 'Middleware::TrackViewSessionIdInjector#call'
config/initializers/008-rack-cors.rb:14:in 'Discourse::Cors#call'
lib/middleware/default_headers.rb:13:in 'Middleware::DefaultHeaders#call'
config/initializers/100-quiet_logger.rb:20:in 'DiscourseRackQuietAssetsLogger#call'
config/initializers/100-silence_logger.rb:29:in 'SilenceLogger#call'
lib/middleware/enforce_hostname.rb:23:in 'Middleware::EnforceHostname#call'
lib/middleware/request_tracker.rb:384:in 'Middleware::RequestTracker#call'
lib/middlewar...

Trace d’erreur :


Backtrace

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

Pour ceux qui se trouvent dans une situation similaire, le contournement fonctionnel qui a permis l’accès administrateur à l’instance Discourse a été de créer un nouveau compte d’utilisateur administrateur en utilisant la commande rake create:admin après être entré dans l’application via ./launcher enter app

Cependant, cela ne résout pas définitivement le problème principal, où les comptes administrateurs existants sont toujours accueillis par la page d’erreur Oops et ne peuvent pas se connecter normalement.

J’espère qu’une correction sera apportée à ce problème à un moment donné et je vous remercie à l’avance pour toute information ou conseil.


Sujets possiblement liés :

En tentant de trouver une solution de contournement en utilisant les fonctionnalités standard de Discourse, je me suis demandé si la fusion de comptes d’utilisateurs pourrait fonctionner. Par exemple, créer un nouveau compte d’administrateur puis le fusionner avec l’ancien compte d’administrateur (pour le personnel, cela doit être fait via la console).

L’autre idée était de révoquer puis de réattribuer le statut d’administrateur, mais je ne sais pas si la révocation pourrait causer des problèmes.

C’est une réflexion de départ de ma part, et je n’ai pas tenté aucune des opérations ci-dessus, mais j’ai expérimenté la création d’un sujet puis le changement de propriété vers le compte d’utilisateur administrateur verrouillé par l’erreur, et ensuite ce Discourse post-notice new-user a affiché ce qui suit :

:tada: C’est la première fois que [nom d’utilisateur] publie — accueillons-les sur le site !

Oh non, c’est comme si l’utilisateur administrateur n’existait pas jusqu’à ce point (changement de propriété) de publication.

Cela pourrait-il indiquer quelque chose ? :thinking:

Je n’y prêtais pas attention, car il s’agissait juste d’« avertissements », mais une erreur MaxMindDB se produit en même temps, juste avant l’erreur ActiveVIEW::Tempalte::Error mentionnée ci-dessus.

MaxMindDB (/var/www/discourse/vendor/data/GeoLite2-City.mmdb) could not be found: No such file or directory @ rb_sysopen - /var/www/discourse/vendor/data/GeoLite2-City.mmdb
MaxMindDB (/var/www/discourse/vendor/data/GeoLite2-ASN.mmdb) could not be found: No such file or directory @ rb_sysopen - /var/www/discourse/vendor/data/GeoLite2-ASN.mmdb

J’ai repéré dans l’onglet ENV :

Jobs::SuspiciousLogin

Peut-être que cette erreur non fatale MaxMindDB, qui n’est qu’un avertissement, bloque-t-elle la connexion de l’utilisateur Admin et affiche-t-elle la page « Oops » pour une raison quelconque, ou fait-elle partie du bug ici ?

S’agit-il d’un problème de configuration incorrecte de MaxMind, fait main ?

L’accès aux fichiers Maxmind est bloqué dans certaines régions. J’ai notamment constaté ce blocage en Chine.

Merci, mais ce serveur Discourse n’est pas situé en Chine, et l’utilisateur administrateur qui tente de se connecter ne s’y trouve pas non plus. Je ne pense pas que MaxMindDB ait jamais été configuré, ou, s’il l’a été partiellement, jamais finalisé.

Je me souvrais vaguement des paramètres MaxMindDB dans l’interface d’administration, mais je ne trouve plus rien pour l’instant.

Je viens aussi de réaliser quelque chose : il faut être connecté en tant qu’administrateur pour voir /logs. L’utilisateur administrateur en question peut donc consulter les journaux, et de là, naviguer vers /admin en utilisant le lien « retour au site ». Cependant, il se retrouve face aux orbes de l’OVNI pulsant (5 cercles bleus). Il a donc au moins dépassé la page « Oops », même si le chemin est plutôt tortueux, mais il n’est toujours pas connecté. :thinking:

Je peux voir dans les journaux que cette activité tortueuse génère davantage d’erreurs de l’OP.

ActionView::Template::Error (no implicit conversion of Array into String)

l’appel est effectué depuis le serveur, l’emplacement de la connexion n’a pas d’importance — cela vaut la peine d’être vérifié

D’accord, mais le serveur n’est pas en Chine.

c’était juste un exemple.

Oh ouais, bien sûr… mince ! :grin: Je ne suis juste pas sûr de ce que je devrais vérifier dans ce cas.

@merefield @Ed_S @Falco La seule occurrence de cette erreur que je puisse trouver et qui ressemble à celle-ci se trouve ici Error "no implicit conversion of Array into String" when using Gemini AI analysis on posts with images Peut-être aurais-je dû publier ce sujet dans la section Contribute > Bug ?

Ça ressemble à quelque chose qui a trait à la présentation des changements à venir — c’est quelque chose que seuls les administrateurs peuvent voir. Selon ask.discourse.com

L’ensemble de la fonctionnalité est contrôlée par un paramètre de site masqué nommé enable_upcoming_changes, défini sur false dans une console Rails :

SiteSetting.enable_upcoming_changes = false

Cependant, cela nécessite un accès terminal/serveur, donc ce n’est possible que sur les installations auto-hébergées.

Merci, j’ai exécuté cette commande dans la console Rails, mais elle m’a répondu « command not found » :thinking:

d’accord, désolé, il s’avère que le LLM m’a fourni des informations obsolètes.

voici quelques commandes que j’ai essayées et utilisées.

pour lister les utilisateurs administrateurs et la valeur de leur paramètre concernant les modifications à venir :

# docker exec -it app rails r 'User.where(admin: true).each { |u| puts "#{u.id} #{u.username} #{u.user_option.enable_upcoming_change_available_notifications}" }'
-1 system true
-2 discobot true
1 AdminTeam false

pour un id donné — dans mon cas 1 — inverser le paramètre pour cet id :

# docker exec -it app rails r 'x=1;User.find(x).user_option.update!(enable_upcoming_change_available_notifications: !User.find(x).user_option.enable_upcoming_change_available_notifications)'

Je préfère plutôt la commande en une ligne depuis le shell racine, bien sûr on pourrait aussi entrer dans docker puis dans rails pour effectuer les actions si on le souhaite.

Je suis toujours un peu désorienté, donc par root shell, tu veux dire accéder via ./launcher enter app et rails c ?

D’accord, la sortie :

-1 system true

Ni les anciens ni les nouveaux administrateurs, discobot, ni personne d’autre n’est répertorié.

Peut-être que c’est le problème : il faut l’appliquer/l’activer pour l’utilisateur administrateur en question. Si c’est le cas, comment trouver son identifiant ?

Ok, j’ai relancé la commande et j’ai trouvé l’identifiant, c’est 1, donc c’est la même configuration.

Cependant, quand j’entres ce qui suit et que je l’exécute, il affiche => true

x=1;User.find(x).user_option.update!(enable_upcoming_change_available_notifications: !User.find(x).user_option.enable_upcoming_change_available_notifications)

Nous voulons que ce soit false, n’est-ce pas ? Je ne vois donc pas ce qui devrait être modifié dans cette commande. J’ai lu l’action comme « find » et rien d’autre, et c’est la sortie => true, ce qui, bien sûr, n’est pas le cas pour l’utilisateur cible.

Je suppose que j’aurais dû adopter une approche plus simple…

# docker exec -it app rails r 'x=1;User.find(x).user_option.update!(enable_upcoming_change_available_notifications: false)'

et de même pour les autres. Je ne sais pas pourquoi je n’y ai pas pensé ainsi.

Je suis dans l’application et dans rails c, je colle ça et ça affiche

=> true

Cependant, je l’ai vérifié et il est bien passé à false dans la sortie tabulée.

J’ai essayé de me connecter, mais je tombe toujours sur l’erreur « Oops ». Est-ce que j’ai besoin de reconstruire ?

Laissez-moi revenir en arrière… ce que je faisais, c’était d’essayer de modifier les préférences d’administration dans l’espoir que le code qui lève l’exception n’aurait pas besoin d’être exécuté.

Mais ce que nous voulons vraiment, c’est vérifier s’il y a un bug dans le code qui nécessite une correction, ou quelque chose d’anormal dans votre base de données qui ne devrait pas y être. Ou bien les deux.

La trace mène à ce code dans app/serializers/current_user_serializer.rb

  def has_new_upcoming_changes
    last_visited = object.custom_fields["last_visited_upcoming_changes_at"]
    return false if last_visited.blank? && object.created_at < Discourse.site_creation_date + 1.hour
    cutoff = last_visited.present? ? Time.zone.parse(last_visited) : object.created_at
    UpcomingChangeEvent.added.not_backfilled.where("created_at > ?", cutoff).exists?
  end

On pourrait exécuter une requête d’explorateur de données pour voir quelle valeur de last_visited_upcoming_changes_at ont vos comptes d’administration.

SELECT 
    ucf.id AS custom_field_id, 
    ucf.user_id, 
    u.username,
    ucf.name, 
    ucf.value 
FROM user_custom_fields ucf
INNER JOIN users u ON u.id = ucf.user_id
WHERE ucf.name = 'last_visited_upcoming_changes_at'
  AND u.admin = true

et cela pourrait être fructueux. Dans mon cas (récemment mis à jour vers v2026.7.3), il s’agit simplement d’une chaîne de date, ce que je pense qu’il devrait être.

Merci pour cela, la réponse contient deux champs personnalisés pour le même ancien utilisateur d’administration, mais les deux entrées ont la même valeur d’heure :

| last_visited_upcoming_changes_at | 2026-09-22T10:30:47Z |
| last_visited_upcoming_changes_at | 2026-09-22T10:30:47Z |

Alors que le nouveau compte d’administration affiche un horodatage plus récent, avec une seule entrée de champ personnalisé pour cet utilisateur.

| last_visited_upcoming_changes_at | 2026-10-02T08:23:22Z |


Version actuelle de Discourse : 2026.10.0-latest