The Git Hang and the Admin/Mod user Accs Oops Error Page Error

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

I recreated the login Oops Page error issue that seems to only affects admins and in some case other staff accounts, but in this case Admin acc, but only admin accs that are pre “git hang” by simply attempting another login.

I then checked the logs now that I am more familiar with how /logs outputs feature works which si excellent!

This error appears as a “fatal error” and it started on the 22nd and appears very similar to the “git hang” issue, but in this case remains unresolved despite various rebuilds up to this point, meaning some admin accounts are essentially locked out, please see info and backtrace logs below:

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

For anyone in a similar predicament, the working work-around here that allowed admin access to the discourse instance, was to create a new admin user account using the rake create:admin command after entering the app via ./launcher enter app

This however does not ultimately solve the problem at hand, where existing Admin accounts are still greeted with the Oops Error page and cannot login as normal.

Hoping there is a fix at some point for this issue and appreciate any insight or tips in advance.


Possible related topics:

In an attempt to curveball a solution using standard Discourse features, I wondered if “merge” users accs might work, say create an new admin users account and then merge it into the old admin user account (for staff needs to be done via the console).

The other idea was to revoke and then re-grant admin status, but I dunno if a revoke might break things.

This is akin to jumpstart thinking on my part, and I have not attempted any of the above but I did play with posting a topic and then changing owernship to the admin user acc locked out by the error, and then this discourse post-notice new-user popped up the following:

:tada: This is the first time [user name] has posted — let’s welcome them to the site!

Oh dear, it’s as if the admin user didn’t exist up to this point of (change ownership) post.

Might this be indicative of anything? :thinking:

I wasn’t paying attention as they were only “warnings” but a MaxMindDB error occurs at the same time but preceding the above ActiveVIEW::Tempalte::Error

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

In ENV tab there is I spotted

Jobs::SuspiciousLogin

Perhaps this MaxMindDB non-fatal error but warning, is creating a blocking of the Admin user acc login but serving the Oops page for whatever reason or part of the bug here?

Is this a case of a half baked or misconfigured MaxMind or another bug?

Maxmind file access is blocked in some regions. I have specifically seen this for China.

Thanks, well this Discourse server is not in China nor is the location of the admin user trying to dial in, and I don’t think MaxMindDB was ever set up, or if partially never finalised.

I vaguely remember MaxMindDB settings in admin but I can’t find anything now.

I also just realised something, you have to be logged in as an admin to see /logs, so the admin user in question can see the logs, and from there can navigate to /admin using the “back to site” link but hits the pulsating UFO orbs (5 blue circles), so that’s at least past the Oops page if rather circuitously, but still not in. :thinking:

I can see in the logs this circuitous activity is generating more of the OP error.

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

the call is made from the server, location of dial-in is irrelevant - worth checking

Ok, but the server is not in China.

that was just an example.

Oh yea of course.. doh! :grin: Just not sure what I should be checking in this case.

@merefield @Ed_S @Falco the only instance of this error I can find that is similar is here Error "no implicit conversion of Array into String" when using Gemini AI analysis on posts with images maybe I should have posted this topic in the Contribute > Bug section?

Kind of looks like something to do with presenting the upcoming changes - that’s something only admins would see. According to ask.discourse.com

The entire feature is controlled by a hidden site setting called enable_upcoming_changes, set to false in a Rails console:

SiteSetting.enable_upcoming_changes = false

However, this requires terminal/server access, so it’s only doable on self-hosted installs.

Thanks, I ran that command in rails console but it told me “command not found” :thinking:

Ok tried that command and got this response:

discourse(prod):001> SiteSetting.enable_upcoming_changes = false

(discourse):1:in '<main>': undefined method 'enable_upcoming_changes=' for class SiteSetting (NoMethodError)

Did you mean?  enable_public_channels=

ok sorry turns out the llm gave me outdated info.

here are some commands I have tried and used.

tabulate the admin users and the value of their setting for upcoming changes:

# 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

for a given id - in my case 1 - flip the setting for that 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)'

I rather prefer the one-liner from the root shell, of course one could enter docker and enter rails and then perform actions if one preferred.

I always get a bit disoriented, so by root shell you mean going in via ./launcher enter app and the rails c?

Ok, the output:

-1 system true

No old or new admins, discobot or nobody else is tabulated.

Maybe that’s the issue, it needs to be applied/turned on for the admin user in question, if so how to find it’s id?

Ok I ran the command again and found the id it’s 1, so the same setup.

However when I input the below and run it, it’s showing => true

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

We want it to be false right, so I can’t see what should be changed in that command. I read the action as “find” and nothing else, this the => true output, which of course is not established for the target user.

Or I don’t understand how to “flip” the setting.

I suppose I should have gone for a simpler approach…

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

and similar. Not sure why I didn’t think of it that way.

I’m in the app and rails c, I paste that in and it outputs

=> true

However, I checked it and it has flipped to false in the tabulated output.

I tried the log in, but still hitting the Oops, maybe I need to rebuild?

Let me backtrack… what I was doing there was trying to change the admin preferences in the hope that the code which throws the exception wouldn’t need to run.

But what we really want is to see if there’s a code bug which needs fixing, or something odd in your database which shouldn’t be there. Or indeed both.

The backtrace leads to this 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

One could run a data explorer query to see what value of last_visited_upcoming_changes_at your admin accounts have.

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

and that might be fruitful. In my case (recently updated to v2026.7.3) it’s just a date string, which I think it should be.

Thanks for this, it’s coming back with two custom fields, for the same old admin user, but both entries with the identical time value:

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

Whereas, new admin account is showing a more up to date time stamp with only one custom field entry for that user.

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

Perhaps the seemingly duplicate entry outputs for the old admin acc is indicative of the problem?


Current Discourse Version: 2026.10.0-latest