I’m seeing the same thing. If I set the Puma worker count to 1 the issue goes away. It appears that each worker is holding a copy of the site settings object, and when one worker performs an update the other workers are never aware of that update.
Unfortunately, this issue is also present in a scaled-out environment with multiple Discourse servers, so just setting the worker count to 1 isn’t a total fix.
I’m trying to do some plugin development, so I followed the link in the README to setup an Ubuntu development environment. When I run the command bundle exec rails server --binding=0.0.0.0 it starts the app with Puma.
The server is still running. I’ve verified from the logs that Discourse is serving the request. I also have cache disabled in my browser’s developer console while I’m debugging this.
Why are you scaling out during plugin development?
The symptoms indicate that your internal MessageBus is broken, so something’s wrong with your Redis setup. Live updates in the browser may also be broken.
I wasn’t scaling out for plugin development, just testing this in a few different scenarios to try to narrow down my issue and make sure I understood it. If the MessageBus is supposed to handle this then I will look into that further.
While debugging, I did notice that app/models/site_setting.rb is still triggering a :site_setting_saved event, which appears to have been removed from the app and replaced with :site_setting_changed. There is nothing listening to the :site_setting_saved event anymore.