Admin-Dashboard mit 2.3.2 defekt

bpetty · 27. August 2019 um 22:37

Ich habe Discourse gerade von Version 2.2.5 auf 2.3.2 aktualisiert, und es scheint ein Regression bei der Verarbeitung der Statistiken im Admin-Dashboard zu geben, die zu einem 500-Fehler führt und mich daran hindert, das Admin-Dashboard zu laden. Alle anderen Admin-Seiten (und die Discourse-Frontend-Seiten) laden jedoch weiterhin korrekt.

Ich habe alle Datenbank-Migrationen mit dem Upgrade ausgeführt.

Hier ist der Fehler und der Aufrufstack, den ich in den Fehlerprotokollen erhalte (ich bin mir ziemlich sicher, dass dies der relevante Fehler ist, der den 500-Fehler verursacht):

TypeError (expected numeric)
/home/docker/.gem/ruby/2.5.0/gems/activesupport-5.2.3/lib/active_support/core_ext/date/calculations.rb:104:in `-'
/home/docker/.gem/ruby/2.5.0/gems/activesupport-5.2.3/lib/active_support/core_ext/date/calculations.rb:104:in `minus_with_duration'
/usr/src/app/app/models/admin_dashboard_general_data.rb:5:in `get_json'
/usr/src/app/app/models/admin_dashboard_data.rb:24:in `as_json'
/usr/src/app/app/models/admin_dashboard_data.rb:16:in `fetch_stats'
/usr/src/app/app/models/concerns/stats_cacheable.rb:28:in `refresh_stats'
/usr/src/app/app/models/concerns/stats_cacheable.rb:23:in `fetch_cached_stats'
/usr/src/app/app/controllers/admin/dashboard_controller.rb:19:in `general'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_controller/metal/basic_implicit_render.rb:6:in `send_action'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/abstract_controller/base.rb:194:in `process_action'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_controller/metal/rendering.rb:30:in `process_action'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/abstract_controller/callbacks.rb:42:in `block in process_action'
/home/docker/.gem/ruby/2.5.0/gems/activesupport-5.2.3/lib/active_support/callbacks.rb:132:in `run_callbacks'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/abstract_controller/callbacks.rb:41:in `process_action'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_controller/metal/rescue.rb:22:in `process_action'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_controller/metal/instrumentation.rb:34:in `block in process_action'
/home/docker/.gem/ruby/2.5.0/gems/activesupport-5.2.3/lib/active_support/notifications.rb:168:in `block in instrument'
/home/docker/.gem/ruby/2.5.0/gems/activesupport-5.2.3/lib/active_support/notifications/instrumenter.rb:23:in `instrument'
/home/docker/.gem/ruby/2.5.0/gems/activesupport-5.2.3/lib/active_support/notifications.rb:168:in `instrument'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_controller/metal/instrumentation.rb:32:in `process_action'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_controller/metal/params_wrapper.rb:256:in `process_action'
/home/docker/.gem/ruby/2.5.0/gems/activerecord-5.2.3/lib/active_record/railties/controller_runtime.rb:24:in `process_action'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/abstract_controller/base.rb:134:in `process'
/home/docker/.gem/ruby/2.5.0/gems/actionview-5.2.3/lib/action_view/rendering.rb:32:in `process'
/home/docker/.gem/ruby/2.5.0/gems/rack-mini-profiler-1.0.2/lib/mini_profiler/profiling_methods.rb:104:in `block in profile_method'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_controller/metal.rb:191:in `dispatch'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_controller/metal.rb:252:in `dispatch'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/routing/route_set.rb:52:in `dispatch'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/routing/route_set.rb:34:in `serve'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/routing/mapper.rb:18:in `block in <class:Constraints>'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/routing/mapper.rb:48:in `serve'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/journey/router.rb:52:in `block in serve'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/journey/router.rb:35:in `each'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/journey/router.rb:35:in `serve'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/routing/route_set.rb:840:in `call'
/home/docker/.gem/ruby/2.5.0/gems/rack-protection-2.0.5/lib/rack/protection/frame_options.rb:31:in `call'
/usr/src/app/lib/middleware/omniauth_bypass_middleware.rb:32:in `call'
/home/docker/.gem/ruby/2.5.0/gems/rack-2.0.7/lib/rack/tempfile_reaper.rb:15:in `call'
/home/docker/.gem/ruby/2.5.0/gems/rack-2.0.7/lib/rack/conditional_get.rb:25:in `call'
/home/docker/.gem/ruby/2.5.0/gems/rack-2.0.7/lib/rack/head.rb:12:in `call'
/usr/src/app/lib/content_security_policy/middleware.rb:12:in `call'
/usr/src/app/lib/middleware/anonymous_cache.rb:220:in `call'
/home/docker/.gem/ruby/2.5.0/gems/rack-2.0.7/lib/rack/session/abstract/id.rb:232:in `context'
/home/docker/.gem/ruby/2.5.0/gems/rack-2.0.7/lib/rack/session/abstract/id.rb:226:in `call'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/cookies.rb:670:in `call'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/callbacks.rb:28:in `block in call'
/home/docker/.gem/ruby/2.5.0/gems/activesupport-5.2.3/lib/active_support/callbacks.rb:98:in `run_callbacks'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/callbacks.rb:26:in `call'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/debug_exceptions.rb:61:in `call'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
/home/docker/.gem/ruby/2.5.0/gems/logster-2.3.0/lib/logster/middleware/reporter.rb:30:in `call'
/home/docker/.gem/ruby/2.5.0/gems/railties-5.2.3/lib/rails/rack/logger.rb:38:in `call_app'
/home/docker/.gem/ruby/2.5.0/gems/railties-5.2.3/lib/rails/rack/logger.rb:28:in `call'
/usr/src/app/config/initializers/100-quiet_logger.rb:18:in `call'
/usr/src/app/config/initializers/100-silence_logger.rb:31:in `call'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/request_id.rb:27:in `call'
/usr/src/app/lib/middleware/enforce_hostname.rb:17:in `call'
/home/docker/.gem/ruby/2.5.0/gems/rack-2.0.7/lib/rack/method_override.rb:22:in `call'
/home/docker/.gem/ruby/2.5.0/gems/actionpack-5.2.3/lib/action_dispatch/middleware/executor.rb:14:in `call'
/home/docker/.gem/ruby/2.5.0/gems/rack-2.0.7/lib/rack/sendfile.rb:111:in `call'
/home/docker/.gem/ruby/2.5.0/gems/rack-mini-profiler-1.0.2/lib/mini_profiler/profiler.rb:281:in `call'
/home/docker/.gem/ruby/2.5.0/gems/message_bus-2.2.0/lib/message_bus/rack/middleware.rb:57:in `call'
/usr/src/app/lib/middleware/request_tracker.rb:163:in `call'
/home/docker/.gem/ruby/2.5.0/gems/railties-5.2.3/lib/rails/engine.rb:524:in `call'
/home/docker/.gem/ruby/2.5.0/gems/railties-5.2.3/lib/rails/railtie.rb:190:in `public_send'
/home/docker/.gem/ruby/2.5.0/gems/railties-5.2.3/lib/rails/railtie.rb:190:in `method_missing'
/home/docker/.gem/ruby/2.5.0/gems/rack-2.0.7/lib/rack/urlmap.rb:68:in `block in call'
/home/docker/.gem/ruby/2.5.0/gems/rack-2.0.7/lib/rack/urlmap.rb:53:in `each'
/home/docker/.gem/ruby/2.5.0/gems/rack-2.0.7/lib/rack/urlmap.rb:53:in `call'
/usr/lib/ruby/vendor_ruby/phusion_passenger/rack/thread_handler_extension.rb:97:in `process_request'
/usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler/thread_handler.rb:149:in `accept_and_process_next_request'
/usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler/thread_handler.rb:110:in `main_loop'
/usr/lib/ruby/vendor_ruby/phusion_passenger/request_handler.rb:415:in `block (3 levels) in start_threads'
/usr/lib/ruby/vendor_ruby/phusion_passenger/utils.rb:113:in `block in create_thread_and_abort_on_exception'

j.jaffeux · 27. August 2019 um 23:38

Hallo,

beim Lesen des Stacktraces vermute ich, dass dies passiert, weil dieser Code nil zurückgibt:

github.com/discourse/discourse

lib/discourse.rb

main


      
            assets << {
              name: "plugins/#{plugin.directory_name}_extra",
              plugin: plugin,
              type_module: false,
            }
          end
          
          if args[:include_admin_asset] && plugin.admin_js_asset_exists?
            if logical_path =
                 Plugin::JsManager.digested_logical_path_for(plugin.directory_name, "admin")
              assets << {
                name: logical_path,
                imports: Plugin::JsManager.import_paths_for(plugin.directory_name, "admin"),
                plugin: plugin,
                type_module: true,
              }
            end
          end
          
          if args[:include_test_assets_for]&.include?(plugin.directory_name) &&
               plugin.test_js_asset_exists?

DateTime.now - nil # TypeError: expected numeric

Ich vermute, unser Code ist hier nicht sehr robust, da wir zwar anerkennen, dass dies nil zurückgeben kann, ihn aber trotzdem so verwenden, als könnte er nicht nil sein.

@david, könntest du bitte einen Blick darauf werfen? FEATURE: Display 'last updated' on dashboard, improve release notes l… · discourse/discourse@5666316 · GitHub

bpetty · 28. August 2019 um 00:36

Das sieht tatsächlich nach dem wahrscheinlichen Problem aus. Zur weiteren Einordnung: Ich betreibe Discourse in einem Docker-Container (wie Sie der Stacktrace vielleicht schon erahnen lassen), aber nicht über das auf docker-compose basierende discourse_docker-Projekt. Das verwendete Docker-Image lädt das Tarball-Release direkt von GitHub herunter, anstatt einen git-Clone durchzuführen. Daher funktioniert keine der git-basierten Logik in der Anwendung.

Ich bin es gewohnt, dass das Feld „Installierte Version“ im Dashboard nicht die tatsächlich installierte Version anzeigt. Das ist schon seit jeher so, wobei es zumindest vorher das Dashboard nicht zum Absturz gebracht hat.

Aus Neugier: Könnte diese Funktion einen Fallback haben, um die Version an einer anderen Stelle als über git abzurufen? Falls nicht, ist das kein großes Problem; es stört mich nicht wirklich, dass ich im Dashboard nicht sehen kann, welche Version ich ausführe.

david · 28. August 2019 um 11:40

Dies sollte das Problem für Sie umgehen:
FIX: Allow dashboard to load even when git version cannot be found · discourse/discourse@ca9ef58 · GitHub

Sie könnten dies in einem Plugin überschreiben. Beachten Sie jedoch, dass wir nur diese Installationsmethode unterstützen: diese hier. Da Sie eine nicht unterstützte Installationsmethode verwenden, können wir nicht garantieren, dass alles korrekt funktioniert.

bpetty · 29. August 2019 um 20:00

Danke, David. Ich melde mich, falls ich damit Probleme habe.

Thema		Antworten	Aufrufe
After update to 2.1.0 admin dashboard have errors and not load Bug	16	1176	15. September 2018
Admin/dashboard-next.json TypeError (no implicit conversion of Date into String) Bug	6	1046	20. Juni 2018
After latest admin/upgrade my Admin dashboard won't load Support	9	2202	20. Juli 2021
Admin dashboard won’t load after upgrade to v2.2.0.beta3 +36 Support	43	3614	28. November 2018
Admin dashboard won't load after upgrade to v2.1.0.beta3 +20 Self-hosting	32	1947	7. August 2018

Admin-Dashboard mit 2.3.2 defekt

Verwandte Themen