-
Notifications
You must be signed in to change notification settings - Fork 8.6k
FIX: Theme site settings not reloading across processes #34242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
efa26a3
to
3db0a7e
Compare
This commit fixes an issue in multi-process setups where the following would happen: 1. Admin changes a theme site setting. The new value is stored in memory in the process that made the change. For this example, changing `enable_welcome_banner` from `true` to `false` 2. Another user visits the site and hits another process, which has the old value of `enable_welcome_banner` still set to `true` in memory 3. The other user's value for `enable_welcome_banner` is cached in the cache for theme site settings, which is shared across all processes The issue is fixed by doing the same thing as site settings: when the new value is saved, we send a MessageBus message to all processes via `SiteSettingExtension` which calls `refresh!` and reloads the in-memory cache of theme site settings from the DB.
3db0a7e
to
1d55156
Compare
@@ -599,6 +600,7 @@ def change_themeable_site_setting(theme_id, name, val) | |||
theme_site_settings[theme_id][name] = val | |||
|
|||
notify_clients!(name, theme_id: theme_id) if client_settings.include?(name) | |||
notify_changed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is the actual fix in this PR
@@ -104,6 +109,30 @@ | |||
expect(settings2.hello).to eq(99) | |||
end | |||
|
|||
it "publishes changes across processes" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Introducing a test to make sure the actual site settings refresh across process behaviour works as expected
expect(result.success?).to eq(true) | ||
|
||
# Get through the MessageBus queue | ||
try_until_success(frequency: 0.5) do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure of a better way to handle this, there isn't a way to make MessageBus process all messages. Without this delay, the spec fails
ae6bf1c
to
aa94137
Compare
aa94137
to
7d18484
Compare
This pull request has been mentioned on Discourse Meta. There might be relevant details there: https://meta.discourse.org/t/difficulty-understanding-the-enable-welcome-banner-setting/377321/27 |
This commit fixes an issue in multi-process setups where the following
would happen:
in the process that made the change. For this example, changing
enable_welcome_banner
fromtrue
tofalse
old value of
enable_welcome_banner
still set totrue
in memoryenable_welcome_banner
is cached inthe cache for theme site settings, which is shared across all
processes
The issue is fixed by doing the same thing as site settings: when the
new value is saved, we send a MessageBus message to all processes via
SiteSettingExtension
which callsrefresh!
and reloads the in-memorycache of theme site settings from the DB.
c.f. https://meta.discourse.org/t/difficulty-understanding-the-enable-welcome-banner-setting/377321