Estou vendo a mesma coisa. Se eu definir a contagem de workers do Puma para 1, o problema desaparece. Parece que cada worker mantém uma cópia do objeto de configurações do site e, quando um worker realiza uma atualização, os outros workers nunca ficam cientes dessa alteração.
Infelizmente, esse problema também ocorre em um ambiente escalado horizontalmente com múltiplos servidores Discourse, então apenas definir a contagem de workers para 1 não é uma solução completa.
Estou tentando desenvolver um plugin, então segui o link no README para configurar um ambiente de desenvolvimento no Ubuntu. Ao executar o comando bundle exec rails server --binding=0.0.0.0, o aplicativo é iniciado com o Puma.
O servidor ainda está em execução. Verifiquei nos logs que o Discourse está atendendo à solicitação. Também desabilitei o cache no console de desenvolvedor do meu navegador enquanto estou depurando isso.
Por que você está escalonando horizontalmente durante o desenvolvimento de plugins?
Os sintomas indicam que seu MessageBus interno está com defeito, então há algo errado com sua configuração do Redis. As atualizações em tempo real no navegador também podem estar quebradas.
Eu não estava escalando para desenvolvimento de plugins, apenas testando isso em alguns cenários diferentes para tentar identificar meu problema e garantir que eu o entendia. Se o MessageBus for responsável por lidar com isso, vou investigar mais a fundo.
Durante a depuração, notei que app/models/site_setting.rb ainda está disparando um evento :site_setting_saved, que parece ter sido removido do aplicativo e substituído por :site_setting_changed. Não há mais nada ouvindo o evento :site_setting_saved.