In a Support thread titled Can we avoid updates that force me to debug on the command line please?, Benjol shares frustration after a Discourse update forced them into command-line debugging due to a plugin conflict — the discourse-data-explorer plugin is now bundled in core and must be removed from app.yml. They wished for a preemptive warning like “get ready, this one is going to hurt” to ease the shock. pfaffman acknowledges the issue, noting the update was unusually disruptive and that warnings should have been clearer, though such breaks are sometimes unavoidable when external components (plugins, Postgres, Redis) are involved. Benjol admits they missed the error buried in verbose logs, a common issue for part-time admins. Kartoon argues logs are the natural place for warnings, while RGJ explains update difficulty depends on pre-update state, not the update itself — sometimes minor versions cause major headaches. Benjol suggests visually highlighting expected errors in logs (e.g., with -- --), and mentions broken backups post-update. tobiaseigen offers sympathy and reminds users that command-line interventions are rare but necessary for self-hosted setups, stressing backup importance. Eventually, Benjol resolved the issue with help from Ask.discourse, discovering a filesystem oversight after expanding a data disk — once fixed, their system stabilized. pfaffman commends the fix, calling it an advanced setup challenge. The thread reflects the tension between user-friendliness and technical reality in self-hosted software maintenance.
Sorry, little from a non-expert, but once again, I start off innocently clicking on the ‘update’ in the UI, then get booted to ‘go do a rebuild from the command line’, and then that fails and I’m pasting bash output into AI for it to tell me what’s wrong.
“The error indicates that the Discourse update failed because the discourse-data-explorer plugin is now bundled with Discourse core and should not be included as a separate plugin in your app.yml configuration file.”
I know that it’s not always possible, but it would be nice to at least have a warning like “get ready, this one is going to hurt”. It could prolong my life expectancy.
It should have printed a warning about exactly that. You could then restart the container with
./launcher start app
And then figured out your next steps more leisurely.
You may still be able to start the container.
But to answer the question in the title, not really. This was a big change and there were notifications here about it. Periodically things need upgrading that are external to the stuff that is just the discourse source code that can be upgraded in the ux.
It’s just that I wasn’t expecting the first rebuild to fail, so that caught me off guard.
The message was there, but I because it was in the wall of log text, I lacked confidence that I would find whatever the problem was. For all I knew it was going to be some obscure exception buried in a call stack. Once AI told me, I saw it was right there near the bottom.
I guess this is what happens when one is a part-part time webmaster
How would a warning someplace else be better than a warning there when both would do the exact same thing and neither have a negative effect outside of reading? The log is always the first place you should look if there’s an error…
The complexity of an update does not depend on the specific update but more on the version your forum is at before the update, and the versions of Postgres, Redis and all the plugins you have.
So it’s basically impossible to tell whether the update is going to “hurt”.
I’ve done updates from 1.8 to 3.5 without issues, and updates from 3.2.1 to 3.2.2 that cost me hours to fix.
I guess one thing that might help, is if this is an ‘expected’ problem (as in, not something buried in a call stack), to surround it with ---- in the log output. That would make it easier to find.
Also, my backup is broken again since the update, back to the grindstone for me
I knuckled down and tackled this on Saturday, with the help of ask.discourse this time.
I discovered that we had a non-standard volumes set up, with uploads and backups on a secondary disk. Which would not have been a problem, but when we grew the data disk from 20GB to 30GB, we omitted to inform the file system!
With that fixed, I’ve now got breathing space for a few more years.
from a non-expert, but once again, I start off innocently clicking on the ‘update’ in the UI, then get booted to ‘go do a rebuild from the command line’, and then that fails and I’m pasting bash output into AI for it to tell me what’s wrong.
