Discourse v3.0.6 to v3.1.1 upgrade error - undefined method `register_bookmarkable' for Bookmark:Class

installation
1

Hi,

I am trying to upgrade my Discourse install from image tag 3.0.6 to 3.1.1 but am seeing the below issue. I know I am using what is deemed an unsupported installation with the Bitnami Helm Chart in a Kubernetes cluster but I am completely stuck on how to resolve.

The error below is being emitted when I try to upgrade from an off the shelf Discourse install (no additional plugins added) to the latest version. Looking at the forum I can see this post - Upgrade failed (NoMethodError: undefined method `register_bookmarkable' for Bookmark:Class) - but it talks about the discourse-data-explorer plugin which as mentioned above is not installed in the default Bitnami Discourse installation.

Can anyone help?

Thanks,

Steve

discourse 07:39:04.07 INFO  ==> Running database migrations
rake aborted!
NoMethodError: undefined method `register_bookmarkable' for Bookmark:Class
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/activerecord-7.0.5.1/lib/active_record/dynamic_matchers.rb:22:in `method_missing'
/opt/bitnami/discourse/plugins/chat/plugin.rb:261:in `block (2 levels) in activate!'
/opt/bitnami/discourse/lib/plugin/instance.rb:1351:in `reloadable_patch'
/opt/bitnami/discourse/plugins/chat/plugin.rb:250:in `block in activate!'
/opt/bitnami/discourse/lib/plugin/instance.rb:526:in `block in notify_after_initialize'
/opt/bitnami/discourse/lib/plugin/instance.rb:524:in `each'
/opt/bitnami/discourse/lib/plugin/instance.rb:524:in `notify_after_initialize'
/opt/bitnami/discourse/config/application.rb:230:in `each'
/opt/bitnami/discourse/config/application.rb:230:in `block (2 levels) in <class:Application>'
/opt/bitnami/discourse/lib/plugin.rb:6:in `initialization_guard'
/opt/bitnami/discourse/config/application.rb:230:in `block in <class:Application>'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/activesupport-7.0.5.1/lib/active_support/lazy_load_hooks.rb:92:in `block in execute_hook'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/activesupport-7.0.5.1/lib/active_support/lazy_load_hooks.rb:85:in `with_execution_control'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/activesupport-7.0.5.1/lib/active_support/lazy_load_hooks.rb:90:in `execute_hook'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/activesupport-7.0.5.1/lib/active_support/lazy_load_hooks.rb:76:in `block in run_load_hooks'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/activesupport-7.0.5.1/lib/active_support/lazy_load_hooks.rb:75:in `each'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/activesupport-7.0.5.1/lib/active_support/lazy_load_hooks.rb:75:in `run_load_hooks'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/application/finisher.rb:87:in `block in <module:Finisher>'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/initializable.rb:32:in `instance_exec'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/initializable.rb:32:in `run'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/initializable.rb:61:in `block in run_initializers'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/initializable.rb:60:in `run_initializers'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/application.rb:372:in `initialize!'
/opt/bitnami/discourse/config/environment.rb:7:in `<main>'
<internal:/opt/bitnami/ruby/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:38:in `require'
<internal:/opt/bitnami/ruby/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:38:in `require'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/bootsnap-1.16.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/zeitwerk-2.6.10/lib/zeitwerk/kernel.rb:38:in `require'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/application.rb:348:in `require_environment!'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/application.rb:506:in `block in run_tasks_blocks'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/opt/bitnami/ruby/bin/bundle:25:in `load'
/opt/bitnami/ruby/bin/bundle:25:in `<main>'
2

I think the first recourse, if this was a web-based update, would be a command line upgrade - ssh to your host and do

cd /var/discourse
git pull
./launcher rebuild app

(Presuming your config is called app.yml)

Edit: except, it looks like /opt/bitnami/discourse is more likely to be the location of your installation. It’s differences like this which lead to the “unsupported-install” tag and the advice to get in touch with your supplier.

1 Like
3

Thanks @Ed_S, I will give the manual upgrade a go.

I have raised a support issue with Bitnami and they are stating that it is a problem with the asset which in this case is the Discourse image. I have asked if they could look at it again as doing an upgrade between their Helm Chart versions should have been tested by Bitnami and any issues they see would hopefully have been resolved between Bitnami and the Discourse team.

2 Likes
4

I’m pretty sure that Bitnami doesn’t work with the discourse team.

If they can’t help and you have a budget you can contact me. I can probably build you an image that will work.

1 Like
5

Thanks @pfaffman

Question - the error I am seeing seems to imply it is from the Chat plugin which is an officially supported plugin - does that make a difference here with regards to the Discourse team looking at the error?

I am going to try and disable it and then perform the upgrade and see how that goes.

6

I think with the Bitnami installs there can sometimes be incompatibility issues with their version and the updated plugins.

If you can move to a standard install you may have an easier time of it (as well as being able to get support from more people on here as well).

1 Like
7

The chat plugin is included. If you are also installing the chat plugin (I think it was separate for a while?) then that could be the problem.

1 Like
8

That’s right. It was initially a separate plugin but has since been bundled in with core, so no need to install it separately any more.

9

Thanks @JammyDodger

Is there a way to disable core plugins at startup so I can test if the Chat plugin is the issue?

The Bitnami chart allows me to pass a list of plugins and it will run the command RAILS_ENV=production bundle exec rake plugin:install repo={{ $plugin }} for each plugin I supply BUT I think that will be on top of the core plugins.

I will look at the standard installation again - we deploy all our 3rd party apps using Helm charts in our kubernetes cluster but maybe it makes sense to make an exception for Discourse if kubernetes and helm support are a long way off.

10

Just a quick update, it seems that performing an upgrade from a pre-3.0.0 version allows the upgrade to work i.e 2.8.11 → 3.0.6 → 3.1.1

I am not sure if this is a pure accident or not but trying to upgrade from 3.0.6 straight to 3.1.1 does not work.

Interestingly the Chat plugin does not even show in my Discourse deployment after this upgrade path. It is thought it is still treated as an external plugin rather than being part of the core product.

Anyone know if the Chat plugin is correct with this upgrade path or is something very wrong that it is not present!

11

Have you enabled it?

Admin → Settings:

image

It’s still a plugin but shipped with core, so enabling it works slightly differently.

12

I will double check my install but I don’t even see the flag.

I don’t see the plugin code on the server either with this upgrade whereas if I start with v3.0.6 I’m sure I do but will double check it all.

13

If you are cloning the official repo, it’s included, here’s the current contents of stable branch: https://github.com/discourse/discourse/tree/stable/plugins/chat

14

@merefield - So I just checked, if I upgrade from version 2.8.11 to 3.0.6 the Chat plugin is not available.

As mentioned above, I am using the Bitnami Helm chart to deploy Discourse which I know is not supported but what is interesting is if I start with version 3.0.6 the Chat plugin is present.

15

Did you remove the chat plugin from your app.yml prior to updating? You should.

16

I didn’t do anything with the Chat plugin but that is not to say that the scrips Bitnami use to build their version of the Discourse image is not impacting it.

This is the Bitnami Discourse repo - https://github.com/bitnami/containers/tree/main/bitnami/discourse and this is how they build the Docker image - https://github.com/bitnami/containers/blob/main/bitnami/discourse/3/debian-11/Dockerfile

17

My suggestion? Just dump a backup and move to the standard install.

18

@stevejr I am stuck in the same pickle. Were you ultimately able to complete your upgrade? I am unable to try the upgrade process starting from 2.8 as you suggested.

19

Unfortunately not. I haven’t performed any upgrades and the response from Bitnami was to do a backup followed by. completely fresh install and then restore.

I need to fully test this out as I don’t want to impact our production setup!

20

I have been trying variations on that approach of a fresh install followed by restoring from backup, but it fails due to what appear to be bugs in the database migration. These attempts are made on an independent dev deployment that is easy to reset. The restore log shows this for example:

...
[2024-02-21 12:43:12] ALTER TABLE
[2024-02-21 12:43:12] Migrating the database...
[2024-02-21 12:43:16] EXCEPTION: /opt/bitnami/discourse/lib/discourse.rb:138:in `exec': Failed to migrate database.
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:

PG::DuplicateTable: ERROR:  relation "sidebar_sections" already exists
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.1.0/lib/patches/db/pg.rb:110:in `exec'
/opt/bitnami/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.1.0/lib/patches/db/pg.rb:110:in `async_exec'
...