-
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_bannerfromtruetofalseold value of
enable_welcome_bannerstill set totruein memoryenable_welcome_banneris 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
SiteSettingExtensionwhich 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