User Crius reports experiencing frequent HTTP 502 (Bad Gateway) and 429 (Too Many Requests) errors after updating their Discourse instance from v3.2.1 to 3.4.0.beta1-dev. Despite following Cloudflare best practices and disabling minification, the issues persisted, including lagging real-time features like unread topic tracking. Server metrics showed no unusual load, but browser console logs confirmed client-side errors. Falco suspected PostgreSQL was overwhelmed despite idle RAM, prompting Crius to ask for tuning guidance. Sidekiq queues showed recurring failed jobs, but no clear root cause emerged. After no resolution, Crius downgraded to v3.2.5, which resolved all issues. This sparked debate with RGJ, who cautioned that downgrading from “tests-passed” to “stable” isn’t officially supported and warned of potential hidden configuration issues. Crius defended the downgrade, criticizing Discourse’s definition of “stable” and the community’s tone, arguing that users shouldn’t be blamed for relying on what’s labeled stable. Moin clarified that Discourse’s “stable” branch means known bugs, not necessarily fewer bugs than “tests-passed”. Crius confirmed v3.2.5 restored stability and advised future readers to consider downgrading if facing similar issues. The thread ended with RGJ reiterating that he offered help voluntarily and that the issue likely stemmed from configuration, not core Discourse bugs.
Yes, sorry, I forgot to add, I had already added the Cloudflare template to the app.yml file a long time ago. We have always been behind Cloudflare, since the very first day.
This is a partial of the app.yml, we have our own certificates independently renewed, which is why the letsencrypt one is commented out:
## this is the all-in-one, standalone Discourse Docker container template
##
## After making changes to this file, you MUST rebuild
## /var/discourse/launcher rebuild app
##
## BE *VERY* CAREFUL WHEN EDITING!
## YAML FILES ARE SUPER SUPER SENSITIVE TO MISTAKES IN WHITESPACE OR ALIGNMENT!
## visit http://www.yamllint.com/ to validate this file as needed
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Uncomment these two lines if you wish to add Lets Encrypt (https)
- "templates/web.ssl.template.yml"
# - "templates/web.letsencrypt.ssl.template.yml"
- "templates/cloudflare.template.yml"
## which TCP/IP ports should this container expose?
## If you want Discourse to share a port with another webserver like Apache or nginx,
## see https://meta.discourse.org/t/17247 for details
expose:
- "80:80" # http
- "443:443" # https
[...]
But… why suddenly? After just an update of the application layer?
I am using the discourse prometheus exporter plugin.
If I added a postgresql exporter as another container on the VM, would it be possible to allow it to access the metrics on the discourse postgresql installation?
You can’t go back from tests-passed to stable, unless there is a higher stable version available. So the next opportunity for you is when 3.4.0 is out, I figure that’s around or after Christmas…
I always mention the version I am in when posting an issue.
I think it’s important to remember that exactly because this is presented as an open source software, critical issues should be considered instead of writing things like this:
This is yet another example of people going out of their way and switching to the “stable” version encountering some bugs that fall between the cracks because it’s a not the most popular version deployed.
When stable should mean “stable”, not “legacy”.
The fact that core dependencies like discourse docker are pushed without a tag system should be enough to be a bit more humble when responding to users that are reporting an issue.
I was talking about mentioning the fact that you downgraded when you technically couldn’t.
I think it’s important to remember… that I do not work for Discourse and I am helping you in my own time, so I do not appreciate your tone, nor am I able to do anything with your feedback.
