I have a failing update and am trying to track down which error message is the cause. All of the updates i’ve done over the past year or two have failed and required a lot of messing around to get them to complete.
I’ve noticed these peer dependency unmet messages during each failed update, but as there wasn’t much discussion about them here, and i eventually got our app to load up, i chose to ignore them until now.
Here’s a sample:
warning " > @glint/environment-ember-loose@1.0.2" has unmet peer dependency "@glimmer/component@^1.1.2".
warning " > @glint/environment-ember-template-imports@1.0.2" has unmet peer dependency "ember-template-imports@^3.0.0".
warning " > @mixer/parallel-prettier@2.0.3" has unmet peer dependency "prettier@^2.0.0".
warning Resolution field "babel-plugin-ember-template-compilation@2.0.0" is incompatible with requested version "babel-plugin-ember-template-compilation@^2.0.1"
warning Resolution field "unset-value@2.0.1" is incompatible with requested version "unset-value@^1.0.0"
warning " > babel-plugin-debug-macros@0.4.0-pre1" has unmet peer dependency "@babel/core@^7.0.0".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/aws-s3@3.0.6" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/aws-s3-multipart@3.1.3" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/xhr-upload@3.1.1" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/aws-s3 > @uppy/xhr-upload@3.3.0" has incorrect peer dependency "@uppy/core@^3.2.1".
This is with all plugins except for Docker Manager turned off in my app.yml file.
The most similar discussion i came across suggested the rebuild issue could be because our droplet was created many years ago and it is there that we are behind on all these versions, so the best solution is to create a new droplet and migrate.
I don’t know why your updates aren’t working and I believe the messages you see aren’t related: there are warnings, not errors.
What kind of “messing around”?
Reinstalling Discourse on a fresh server is quite easy and fast (depending on your forum size, of course), so you could also do that, it might solve the unidentified issue. If I were you, I’d sure like to know what is the problem, though.
Well, we’ve got a repeated tag somehow and its stopping the app from rebuilding, which i can fix by following this guide:
…but i can’t enter the app to fix it as its not running and won’t start or rebuild.
I was thinking that it might be due to those errors, and because our Docker and Ubuntu are a bit dated.
I guess i’m going to try and spin up a new Discourse on a new droplet, install Discourse and then restore our latest backup into it via command line so i can hopefully fix the repeated tag in the DB and reload the app.
I would also like to know the reason for these warnings, after seeing these now I’m getting a failed build also.
111:M 25 Sep 2023 23:13:54.237 # Redis is now ready to exit, bye bye...
/usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:110:in `readlines': Interrupt
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:110:in `block in spawn'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:103:in `popen'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:103:in `spawn'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:80:in `block in run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:78:in `each'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:78:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/command.rb:8:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:152:in `block (2 levels) in run_commands'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:142:in `each'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:142:in `block in run_commands'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:141:in `each'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:141:in `run_commands'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:124:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/cli.rb:65:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/bin/pups:9:in `<top (required)>'
from /usr/local/bin/pups:25:in `load'
from /usr/local/bin/pups:25:in `<main>'
I was on the stable 3.1.1 build, edited the app.yml file to include the data explorer plugin and now it’s failing. I haven’t done a complete rebuild in a while, used only the web admin console to update discourse and never had an issue until now. The Ubuntu system is up to date on all the packages.
UPDATE: Rebuilding it a 2nd time seemed to fix itself, the warnings still appear but it rebuilt successfully. Would be interesting to know why the warnings are now appearing and their impact (if any)
There are many ways to fix this before it gets out of hand. Normally you can rebuild, or reload a previous backup and fix the duplicate in the admin area. Mine did get out of hand, here’s a worst case scenario for manually fixing the DB if it ever happens to you:
