Git-Hang und Admin/Mod-Benutzerkonten: Oops-Fehlerseite

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

Ich habe das Problem mit der Oops-Seite-Fehlermeldung beim Login reproduziert, das anscheinend nur Admins und in einigen Fällen andere Mitarbeiterkonten betrifft, in diesem Fall jedoch ein Adminkonto – und zwar nur Adminkonten, die vor dem “git hang” aufgetreten sind, indem ich einfach einen weiteren Login-Versuch unternahm.

Anschließend habe ich mir die Logs angesehen, da ich mittlerweile besser mit der Funktionsweise der /logs-Ausgabe vertraut bin, was hervorragend ist!

Dieser Fehler erscheint als „fatal error“ und trat erstmals am 22. auf. Er ähnelt stark dem “git hang”-Problem, bleibt in diesem Fall jedoch trotz verschiedener Rebuilds bis jetzt ungelöst. Das bedeutet, dass einige Adminkonten im Wesentlichen gesperrt sind. Bitte sehen Sie sich die folgenden Informationen und Backtrace-Logs an:

Info

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...

Backtrace:


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

Für alle, die sich in einer ähnlichen Lage befinden: Der hier funktionierende Workaround, der Admin-Zugriff auf die Discourse-Instanz ermöglichte, bestand darin, nach dem Einstieg in die App über ./launcher enter app ein neues Admin-Benutzerkonto mit dem Befehl rake create:admin zu erstellen.

Dies löst das eigentliche Problem jedoch nicht endgültig, da bestehende Adminkonten weiterhin mit der Oops-Fehlerseite begrüßt werden und sich nicht wie gewohnt anmelden können.

Ich hoffe, dass es irgendwann eine Lösung für dieses Problem gibt, und freue mich im Voraus über jegliche Erkenntnisse oder Tipps.


Möglicherweise verwandte Themen:

In dem Versuch, mit den Standardfunktionen von Discourse eine Lösung zu finden, die den erwarteten Kurs ändert, fragte ich mich, ob das Zusammenführen von Benutzerkonten funktionieren könnte. Man könnte beispielsweise ein neues Admin-Benutzerkonto erstellen und es dann in das alte Admin-Benutzerkonto zusammenführen (dies muss für Mitarbeiter über die Konsole erfolgen).

Die andere Idee war, den Admin-Status zu entziehen und dann wieder zu erteilen, aber ich weiß nicht, ob ein Entzug Dinge kaputt machen könnte.

Das ist eher ein Bauchgefühl von mir, und ich habe noch nichts davon ausprobiert. Ich habe jedoch damit experimentiert, ein Thema zu erstellen und dann die Eigentümerschaft auf das durch den Fehler gesperrte Admin-Benutzerkonto zu übertragen. Daraufhin erschien in diesem Discourse-Forum die Benachrichtigung post-notice new-user mit folgendem Inhalt:

:tada: Dies ist das erste Mal, dass [Benutzername] gepostet hat — lass uns sie/ihn auf der Seite willkommen heißen!

Oh je, es ist, als hätte das Admin-Benutzerkonto bis zu diesem Zeitpunkt (der Eigentümerschaftsänderung) nicht existiert.

Könnte dies auf etwas hinweisen? :thinking:

Ich habe nicht aufgepasst, da es sich lediglich um “Warnungen” handelte, aber gleichzeitig tritt ein MaxMindDB-Fehler auf, der dem oben genannten ActiveVIEW::Tempalte::Error vorausgeht.

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

Im Reiter ENV habe ich Folgendes bemerkt:

Jobs::SuspiciousLogin

Vielleicht blockiert dieser nicht fatale MaxMindDB-Fehler, der eigentlich nur eine Warnung ist, das Login des Admin-Benutzers und zeigt aus irgendeinem Grund oder als Teil des Bugs hier die Oops-Seite an?

Handelt es sich hier um ein manuell verursachtes Konfigurationsproblem mit MaxMind?

Der Zugriff auf Maxmind-Dateien ist in einigen Regionen blockiert. Dies habe ich insbesondere für China festgestellt.

Danke. Dieser Discourse-Server befindet sich jedoch nicht in China, und auch der Ort, von dem der betreffende Admin-Benutzer versucht, sich zu verbinden, liegt nicht dort. Ich glaube auch, dass MaxMindDB nie eingerichtet wurde, oder dass eine teilweise Einrichtung nie abgeschlossen wurde.

Ich erinnere mich vage an MaxMindDB-Einstellungen im Admin-Bereich, kann aber jetzt nichts davon finden.

Außerdem ist mir gerade etwas aufgefallen: Man muss als Admin eingeloggt sein, um /logs zu sehen. Der betreffende Admin-Benutzer kann also die Logs einsehen und von dort über den Link „Zurück zur Website“ zu /admin navigieren. Dort sieht er dann die pulsierenden UFO-Orbs (5 blaue Kreise). Er ist also zumindest an der Oops-Seite vorbeigekommen, wenn auch auf einem recht umständlichen Weg, aber er ist immer noch nicht drin. :thinking:

In den Logs kann ich sehen, dass diese umständliche Aktivität weitere OP-Fehler erzeugt.

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

der Anruf wird vom Server ausgeführt, der Standort der Einwahl ist irrelevant – es lohnt sich, das zu überprüfen

Okay, aber der Server steht nicht in China.

Das war nur ein Beispiel.

Oh ja, natürlich.. doof! :grin: Nur weiß ich in dem Fall nicht, worauf ich achten soll.

@merefield @Ed_S @Falco Die einzige ähnliche Instanz dieses Fehlers, die ich finden kann, ist hier: Error "no implicit conversion of Array into String" when using Gemini AI analysis on posts with images Vielleicht hätte ich dieses Thema im Abschnitt Contribute > Bug posten sollen?

Sieht irgendwie so aus, als hätte es mit der Darstellung anstehender Änderungen zu tun – das sehen nur Admins. Laut ask.discourse.com

Die gesamte Funktion wird durch eine versteckte Einstellung namens enable_upcoming_changes gesteuert, die in einer Rails-Konsole auf false gesetzt wird:

SiteSetting.enable_upcoming_changes = false

Dafür ist jedoch Terminal-/Server-Zugriff erforderlich, was nur bei selbst gehosteten Installationen möglich ist.

Danke, ich habe den Befehl in der Rails-Konsole ausgeführt, aber es wurde mir „command not found“ angezeigt :thinking:

ok, sorry, die LLM hat mir veraltete Infos gegeben.

hier sind ein paar Befehle, die ich probiert und verwendet habe.

Admin-User tabellarisch auflisten und den Wert ihrer Einstellung für anstehende Änderungen anzeigen:

# 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

für eine gegebene ID – in meinem Fall 1 – die Einstellung für diese ID umschalten:

# 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)'

Ich bevorzuge natürlich den One-Liner aus der Root-Shell. Man könnte sich natürlich auch in den Docker-Container einloggen, in Rails gehen und dann dort Aktionen ausführen, wenn man das lieber möchte.

Ich bin immer etwas desorientiert, meinst du mit Root-Shell, dass man über ./launcher enter app und rails c reingeht?

Okay, die Ausgabe:

-1 system true

Weder alte noch neue Admins, Discobot oder sonst jemand sind aufgeführt.

Vielleicht liegt es daran, dass es für den betreffenden Admin-Benutzer aktiviert werden muss. Falls ja, wie findet man dessen ID heraus?

Okay, ich habe den Befehl erneut ausgeführt und die ID gefunden: Sie ist 1, also dasselbe Setup.

Wenn ich jedoch den folgenden Befehl eingabe und ausführe, wird => true angezeigt:

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

Wir wollen, dass es false ist, oder? Ich kann nicht erkennen, was in diesem Befehl geändert werden sollte. Ich verstehe die Aktion als „finden“ und nichts anderes. Dies ist die Ausgabe => true, die natürlich für den Zielbenutzer nicht gesetzt ist.

Ich hätte wohl einen einfacheren Ansatz wählen sollen…

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

und ähnliche Befehle. Ich weiß nicht, warum mir das nicht eingefallen ist.

Ich bin in der App und in rails c, ich füge das ein und es gibt aus

=> true

Ich habe es mir aber angesehen und es ist in der tabellarischen Ausgabe tatsächlich auf false umgeschaltet.

Ich habe mich eingeloggt, aber ich stoße immer noch auf den Oops-Fehler. Muss ich vielleicht neu bauen?

Lass mich kurz zurückspulen… Was ich dort gemacht habe, war, die Admin-Einstellungen zu ändern, in der Hoffnung, dass der Code, der die Ausnahme auslöst, nicht ausgeführt werden muss.

Aber was wir wirklich herausfinden wollen, ist, ob es einen Code-Fehler gibt, der behoben werden muss, oder ob es in deiner Datenbank etwas Seltsames gibt, das dort nicht sein sollte. Oder tatsächlich beides.

Die Backtrace führt zu diesem Code in 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

Man könnte eine Data-Explorer-Abfrage ausführen, um zu sehen, welchen Wert last_visited_upcoming_changes_at deine Admin-Konten haben.

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

und das könnte fruchtbar sein. In meinem Fall (kürzlich aktualisiert auf v2026.7.3) ist es nur ein Datumsstring, was meiner Meinung nach auch so sein sollte.

Danke dafür, es werden zwei benutzerdefinierte Felder für denselben alten Admin-Benutzer zurückgegeben, wobei beide Einträge denselben Zeitwert aufweisen:

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

Während ein neues Admin-Konto einen aktuelleren Zeitstempel mit nur einem Eintrag für das benutzerdefinierte Feld für diesen Benutzer anzeigt.

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


Aktuelle Discourse-Version: 2026.10.0-latest