Potentially…but to me that wouldn’t explain this weird lag you are seeing between changes of the settings. Also we don’t use the old site setting value past the initial migration, so I don’t think it should affect things.
Okay this is interesting…it’s missing on Foundation on your site again Moin, even though it’s enabled in the admin UI. Clearing the cache with SiteSetting.clear_cache!(expire_theme_site_setting_cache: true)
is not clearing the cache. I get two different results here:
discourse(prod)> SiteSetting.theme_site_settings_json_uncached(-1)
=> "{\"enable_welcome_banner\":true,\"search_experience\":\"search_field\"}"
discourse(prod)> SiteSetting.theme_site_settings_json(-1)
=> "{\"enable_welcome_banner\":false,\"search_experience\":\"search_field\"}"
And then I just ran this directly:
Discourse.cache.delete(SiteSettingExtension.theme_site_settings_cache_key(-1))
And it worked?? Then I changed your setting again in admin and the cache is persisting I think something weird is happening with the
theme_site_settings
in memory here:
Because that is giving:
-2=>{:enable_welcome_banner=>false, :search_experience=>"search_field"},
-1=>{:enable_welcome_banner=>true, :search_experience=>"search_field"}}
Whereas if I fetch from the DB, I get this, which has the proper false
value:
ThemeSiteSetting.where(theme_id: -1)
=>
[#<ThemeSiteSetting:0x00007f9164acb2d0 id: 3, theme_id: -1, name: "enable_welcome_banner", data_type: 5, value: "f", created_at: "2025-07-16 07:04:11.117747000 +0000", updated_at: "2025-08-11 06:35:07.606301000 +0000">,
#<ThemeSiteSetting:0x00007f9164acb190 id: 13, theme_id: -1, name: "search_experience", data_type: 7, value: "search_field", created_at: "2025-07-16 07:04:11.117747000 +0000", updated_at: "2025-07-20 20:56:49.405228000 +0000">]
discourse(prod)> Theme.find(-1).themeable_site_settings
=>
[{:setting=>:enable_welcome_banner, :default=>true, :description=>"Display a banner on your main topic list pages to welcome members and allow them to search site content", :humanized_name=>"Enable welcome banner", :type=>"bool", :value=>false},
{:setting=>:search_experience,
:default=>"search_icon",
:description=>"The default position and appearance of search on desktop devices",
:humanized_name=>"Search experience",
:type=>"enum",
:valid_values=>[{:name=>"search.experience.search_field", :value=>"search_field"}, {:name=>"search.experience.search_icon", :value=>"search_icon"}],
:translate_names=>true,
:value=>"search_field"}]
We fiddle with this here:
And here:
Which is called here:
So I am not sure why this happening yet, but it would explain why the cache is holding on, because the cache is built from this object in memory.
Edit: Also note, I still can’t reproduce this elsewhere, but I can reproduce it quite reliably on your site.
Okay…I think I’ve got it reproducing locally, it’s a multi-process bug. Basically the in-memory version of the settings get changed by the admin in process A, but then a user hits process B with a request and ends up being the one setting the new cache value, and the cache ends up with the old value in memory.
Other site settings get around this by refreshing all settings via MessageBus whenever anyone changes:
I will try have a fix for this tomorrow (it’s my EOD now), thanks for your patience here Moin!
Merged the fix now, it took a while longer because I needed to figure out how to test it:
I will deploy your site soon Moin.
Edit: Fix has been deployed
Closing since I haven’t heard about further issues, feel free to let me know if there are issues.