Internal Server Error on Upgrade page

[Campano]

Hello,

I just got an error on the upgrade page, is there a documented way to debug / report those cases?

Thank you for your help !

[JammyDodger]

You should be able to find more information on your /logs page for the error. If you could share what you find here that should help us figure out what’s going on.

[pfaffman (Jay Pfaffman)]

There was a recently fixed big relating to the new version numbering system. I can’t find it, but doing a command line upgrade should fix it.

[JammyDodger]

This one?

Version Check job is raising an exception on latest tests-passed

Thanks @merefield - the version check server needed some tweaks to understand the new -dev suffix on tests-passed version numbers. Should be working now: [7] pry(main)> Discourse::VERSION::STRING => "3.2.0.beta1-dev" [8] pry(main)> DiscourseHub.discourse_version_check => {"success"=>"OK", "latestVersion"=>"3.1.0.beta7", "criticalUpdates"=>false, "missingVersionsCount"=>0}

[david (David Taylor)]

That one required a fix on our central version check server, so it should be fixed everywhere now. Rebuilding won’t change anything. Also I don’t think that one was affecting the /admin/upgrade path

[Campano]

That’s what the logs show when I trigger the error:

Screenshot

Message (7 copies reported)

ArgumentError (Malformed version number string < 3.1.0.beta6)
lib/version.rb:44:in `block in find_compatible_resource'
lib/version.rb:44:in `each'
lib/version.rb:44:in `sort_by'
lib/version.rb:44:in `find_compatible_resource'
lib/version.rb:79:in `find_compatible_git_resource'
app/controllers/application_controller.rb:420:in `block in with_resolved_locale'
app/controllers/application_controller.rb:420:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:74:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:369:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:228:in `call'

Backtrace

/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/version.rb:223:in `initialize'
/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/version.rb:206:in `new'
/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/version.rb:206:in `new'
lib/version.rb:44:in `block in find_compatible_resource'
lib/version.rb:44:in `each'
lib/version.rb:44:in `sort_by'
lib/version.rb:44:in `find_compatible_resource'
lib/version.rb:79:in `find_compatible_git_resource'
plugins/docker_manager/lib/docker_manager/git_repo.rb:153:in `tracking_branch'
plugins/docker_manager/lib/docker_manager/git_repo.rb:100:in `tracking_ref'

[david (David Taylor)]

Thanks @Campano. We were hoping this docker_manager problem would be handled via this commit, but it looks like we have some more work to do here.

In the meantime, I’d recommend following @pfaffman’s advice of doing a command line rebuild (./launcher rebuild app) - that should get everything up-to-date and working properly

[david (David Taylor)]

I’ve posted this topic describing the error, and how to recover:

Visiting /admin/upgrade may lead to a server error

If you’re currently running a standard installation of Discourse earlier than v3.1.0.beta7 (or stable earlier than v3.0.6), there is a chance you will be met with this error when attempting to upgrade via the admin UI: Server Error while trying to load /admin/docker/repos Error code: 500 error [admin upgrade error message screenshot] To resolve the issue, you will need to run a command-line rebuild: cd /var/discourse ./launcher rebuild app Once you’ve run a CLI upgrade, future upgrades…

[Campano]

Thank you so much @david, that worked for me.