# Settings revert back on their own

I have a discourse instance that has been up for a week now and it has some of the weirdest symptoms that I cant solve partly because there is nothing at all showing up in the logs that are useful.

The most noticeable symptom is that if i go into the settings and change a setting, then hit the green check mark it accepts it and all looks good. If i then refresh the settings page there is a good chance it might show the old setting or the new. If i continue to refresh sometimes it shows one setting, sometimes the other.

Worse yet it isnt just in the settings screen itself but sometimes the functionality of the server itself sees to change. For example if i try uploading a new logo it may sometimes show the old and sometimes the new.

To answer the obvious question: no I am not running multiple instances behind a load balancer, single instance.

I’m not sure if it is related but i also notice the discourse math plugin doesnt render right either. While the equations do show correctly int he preview once i post it the javascript doesnt appear to get included and thus doesnt render properly. The math issue isnt the priority here so just mentioning it here in case it offers any more clues.

I’m really stuck here, with the logs all looking normal I’ not even sure what to post to get help. Any ideas would be great.

1 Like

This implies a seriously busted install. Remove all third party plugins and rebuild.

1 Like

I tried this with no luck. Most likely something broken in how I’m installing it or something.

I am a developer myself, any idea what might be busted in an install that would cause this. Some sort of hint as to where to debug and troubleshoot?

How are you installing are you using the official Guide Provided on Github

1 Like

Originally that was the process I went with. Unfortunately it does not support most of the Enterprise level production environments I have at my disposal. Most of the frameworks operate, launch, and deploy containers. Because of the nature of the standard install approach it is not possible to work in these tools and environments.

As such I am trying to enhance/fix the process so it can install anywhere that supports a standard docker based deployment. While this effort is mostly working it is the bug I originally posted that I’m struggling with.

Once I get it working I will of course release it for others. I spent the last year waiting for discourse to support standard docker, but figured I’d just make the contribution myself. So close too, but hopefully someone with more expiernce then I can tell me where to look.

1 Like

Any help please? Even just a hint where to look or where to debug this or ideas would be greatly appreciated.

Are you sure the request is getting through fine? What do you see in the network tab of the developer tools?

The behavior you describe is typical for an environment that is erroring on the Javascript side.

1 Like

Thank you, this may prove to be very helpful. Since the MathJax plugin seemed to sporadically work than stop as well it seems likely it is javascript related.

I just went in and tried to set a setting after clearing the cache, making sure to watch the network tab. No errors showed up before or after changing a setting (even though the bug did present itself).

One reason it doesnt make sense that the change isnt getting through at all is the behavior. I make a change,then refresh and the change appears to be reverted. But if i continue to just refresh (without trying to make the change a second time) then the change does show up about half the time. Every time i refresh it has about a 50% chance of showing the old setting vs showing the new.

I also did find the following error in the console but I think it is unrelated?

Could not find widget actions-summary-item in registry

Just try safe mode to quickly eliminate all those plugins.

Do you have multiple web containers running?

I tried this, as I had before. It didnt help. But I’m skeptical if i was truly in safe mode. I went to the */safe-mode got the dialog to enter safe mode. I accepted it. But what i noticed is the Material Design theme I use was still displaying. So while I thought I was in safe mode maybe I wasnt really?

Regardless the bug did persist.

I don’t think he is…

2 Likes

Two containers one for sidekiq one for core discourse. Only one instance of the pair. I’m running postgres and redis as hosted services on separate machines…

1 Like

Oops. Sorry that was the obvious question that you m already answered.

Edit: maybe this isn’t it either, but I had a similar problem when I was using a redis database that was in use by another process.

I think i realized why safe-mode wasnt working. It was turning off when i refresh.

Just tested in safe mode, problem still persists.

1 Like

And the API call is returning 200 ?

Depends what you mean. In the “inspect” network tab for debugging everything shows as 200, the console only has the error i mentioned above (probably unrelated). In the docker logs when i go to make the setting I see the following confirming it was successful. Yet when i refresh the setting page 50% of the time it shows the ld setting and 50% of the time the new.

> 2019-08-20T13:14:15.960335498Z Started PUT "/admin/site_settings/categories_topics" for 213.127.19.53 at 2019-08-20 13:14:15 +0000
> 2019-08-20T13:14:15.968667966Z Processing by Admin::SiteSettingsController#update as */*
> 2019-08-20T13:14:15.968951769Z   Parameters: {"categories_topics"=>"25", "id"=>"categories_topics"}
> 2019-08-20T13:14:15.978407541Z   Rendering text template
> 2019-08-20T13:14:15.978607623Z   Rendered text template (0.0ms)
> 2019-08-20T13:14:15.978834745Z Completed 200 OK in 10ms (Views: 0.6ms | ActiveRecord: 0.0ms)
> 2019-08-20T13:18:39.821498901Z [ N 2019-08-20 13:18:39.8209 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 6157, application /opt/bitnami/discourse (production)
> 2019-08-20T13:18:59.866033984Z [ N 2019-08-20 13:18:59.8655 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 5973, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:04.848923491Z [ N 2019-08-20 13:19:04.8484 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 6018, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:08.900933057Z [ N 2019-08-20 13:19:08.9004 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 5995, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:09.499349110Z [ N 2019-08-20 13:19:09.4989 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 6041, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:29.645095032Z Creating scope :open. Overwriting existing method Poll.open.


So how was it installed? If you aren’t using the standard install what installation method and package are you using?

Ouch… bitnami…

What kind of processes are those that are being referred to?

It isnt using the standard install, though i did use it as a guide to learn from. I basically had to write/modify the docker files to get them to work with a docker-compose. Then one the docker compose was working locally I converted that to its JSON form so it could be used with aws-cli tools.

So the install process is a considerable change from the standard.