Upgrading from /admin/upgrade takes *very* long

While upgrading a single plugin from admin/upgrade it takes very long.

Usually a full rebuild is done in about 7 minutes.

It has been upgrading since 2023-03-02T20:07:00Z, the status now is:

HTOP output:

EDIT: 2023-03-02T20:44:00Z - still at the same log line. CPU still the same. Initiated CLI rebuild at this point.

EDIT2: To reference the exact time a rebuild takes on my machine, rebuild completion timestamp: 2023-03-02T20:51:00Z


Yeah, I’ve been experiencing the same thing since at least yesterday.

It’s now more or less impossible to upgrade from the upgrade screen in reasonable time atm, so you are forced to upgrade from the command line.

CLI rebuild has been completed.

Admin upgrade is still stuck and it doesn’t look like the plugin is upgraded.


I clicked RESET UPGRADE and initiated another cli-rebuild.

1 Like

Me too, I have the exact same thing. Very irritating when upgrading plugins, it takes really really long - Extremely inconvenient.


Is there any work around for this? Every time I upgrade to keep up with the changes on Discourse Chatbot :robot: (Supports ChatGPT) - plugin - Discourse Meta, it takes so so long.

This is still an issue.

However, it seems to affect only the lower spec servers?

1 Like

Just to add an extra voice rather than any answers… :slight_smile:

I have a tiny 1GB DO test site with lots of plugins, so it’s not normally the quickest. However, I think it’s been taking a lot longer recently too, and mine got caught in a weirdness the other day like @MarcP and I had to reset it.

I have never timed it before, but today I set it to ‘Update All’ and made a note of when I clicked the button. So far we have a 9:30 am start, and it’s still going at 10:15. It’s currently bundling some assets. I can say with some confidence that it doesn’t normally take over 45 minutes and counting to do its thing.

Though it looks like it had some permission issues purging temp files? Not sure if that’s relevant.


@david and I found the root cause. (similar to what @Falco found in the past)

We use special Ruby flags to try to limit memory during upgrades and this no longer works on Ruby 3.2.

We should have a PR shortly to fix the issue.


Note… for fix to take effect, there is a bit of a chicken meets egg situation. Old code is still loaded when you run the upgrade.

You may need a ./launcher rebuild for the first time, and subsequent times the web upgrader will be fine.

No easy way around this. @CvX its a tricky problem… technically we should have it so DockerManager::Upgrader.new(user_id, repo, repo_version).upgrade shells out and runs new upgrader code when it upgrades … but its a can of snakes.

Fast workaround

  1. Start upgrading docker manager
  2. Cancel when it gets stuck
  3. ./launcher restart app from the shell
  4. Upgrade from web will work.

Easy workaround

  1. ./launcher rebuild app

Everything is fine after this.


Closing this preemptively cause I want this to be the last post on this topic. Which will make it easy for people to find the workarounds. Flag to open if still an issue after a rebuild.